stasn1

for state in /sys/devices/system/cpu/cpu*/cpuidle/state[2-9]*/disable ; do echo 1 > $state ; done

Мне, например, не нужна высокая производительность при отправке резетов/редиректов. Поэтому для этих отправок и управления сервером использую вланы на одной сетевой. Подправил немного исходники и ExtFilter (DPDK) сам создает при запуске tap интерфейс для отправок, который потом биндится на нужный мне влан.

Можно же завернуть неTCP трафик фильтром с меньшим номером в класс без шейпера на нем... А вместо drr можно, наверное, соорудить дерево из HFSC или HTB если нужно резать и суммарную полосу.

Да.

dev=imq0 tc qdisc del dev $dev root tc qdisc add dev $dev handle 1025: root drr for i in $(seq 1 1024); do h=$(printf %x $i) tc class add dev $dev parent 1025: classid 1025:$h drr tc qdisc add dev $dev parent 1025:$h handle $h: netem rate 1Mbit done tc filter add dev $dev protocol ip handle 1025 parent 1025: flow hash keys src,dst,proto,proto-src,proto-dst divisor 1024 perturb 10

Испытал на себе тоже, сегодня. Откатился на ядро 3.16.7-992-generic. И все отлично, извините за флуд. Но на 4.x ветке что-то поломали.... Хотелось бы комментарий .... Спецов :) Тоже столкнулся. Вычислил, что баг появился после коммита eb3b85388944b4e15b6db2db99d136f538384c4e - preparation for DPDK intergation (part 7). У себя временно вылечил вот так: --- a/accel-pppd/ppp/ppp.c.orig 2016-05-31 15:46:37.000000000 +0300 +++ b/accel-pppd/ppp/ppp.c 2016-05-31 15:47:33.046457966 +0300 @@ -353,7 +353,7 @@ while(1) { cont: ppp->buf_size = net->read(h->fd, ppp->buf, PPP_BUF_SIZE); - if (ppp->buf_size < 0) { + if (ppp->buf_size < 1) { if (errno != EAGAIN) { log_ppp_error("ppp_chan_read: %s\n", strerror(errno)); ap_session_terminate(&ppp->ses, TERM_NAS_ERROR, 1); @@ -401,7 +401,7 @@ while (1) { cont: ppp->buf_size = net->read(h->fd, ppp->buf, PPP_BUF_SIZE); - if (ppp->buf_size < 0) { + if (ppp->buf_size < 1) { if (errno != EAGAIN) { log_ppp_error("ppp_unit_read: %s\n",strerror(errno)); ap_session_terminate(&ppp->ses, TERM_NAS_ERROR, 1); Ядро - 4.4.12.

Я уже писал выше про подобный вариант. Сейчас рулю у себя по метке skb->priority, но можно и fwmark как доп.вариант.

можно сразу как-то так -m ndpi --proto http,http_proxy,http_connect,ssl -j CLASSIFY --set-class 1:10 -m ndpi --proto ftp_control,ftp_data -j CLASSIFY --set-class 1:11 -m ndpi --proto bittorrent -j CLASSIFY --set-class 1:12

Говорю же: грязный хак. ) - addr = ip_hdr(skb)->daddr; + addr = skb->priority; Оба - целые 32битные числа. Дальше сервисная связка, например, a027 соответствует у меня qdisc 10:a027. Путем нехитрых манипуляций она превращается в ip-адрес 39.160.16.0 (я прямо в селекте из базы конвертирую). Ну а дальше этот адрес добавляю в правило.

Почему же лишнее?! В моем случае при использовании шейпера на tc qdisc фильтр просто перемещается из tc filter в ipset/iptables. Даже, наверное, учитывая то, что в один qdisc может залетать несколько ip/net (т.е. нужно было несколько фильтров), то и некая оптимизация что ли получается. Да и проще само по себе так, по-моему. Я для собственных нужд только что добился нужного функционала от ipt_ratelimit при помощи грязного хака и пары костылей, заменив полстрочки в исходниках. Проверил - раскидывает по правилам по номеру сервисной связки. )

У меня аналогичная ситуация, возможное универсальное решение описал выше. В моем случае это "ipset add clients 1.1.1.0/30 skbprio 10:b552", где $b552 - это и есть номер сервисной связки. И таких элементов в ipset с одинаковым номером может быть несколько. Потом этот номер копируется в поле skb->priority по "iptables ... -j SET --map-set clients dst --map-prio" и как результат сразу летит в нужный класс шейпера без какого-либо фильтра в нем. Было бы идеально если бы появилась такая возможность сразу по skb->priority заруливать трафик в нужное правило и в ipt-ratelimit.

Каким образом? Мне, например, сразу представилась следующая схема: Сейчас я для шейпера на tc через -j SET --map-set anyname dst --map-prio (или map-mark) некой группе адресов, сетей назначаю сразу номер класса в шейпере, несколько разных адресов могут иметь одинаковый номер класса, так как принадлежат одной и той же услуге. Что избавляет от необходимости использовать потом "tc filter". В моем случае было бы идеально сделать возможность задавать полосы в xt_ratelimit не только по списку одиночных ip-адресов (или подсетей когда реализуются префиксы), но и по номеру в skb->priority (и skb->mark). А то сейчас мало того что приходится каждую подсеть парсить в список отдельных адресов, так еще если у клиента несколько таких сетей-адресов, то и склеивать потом в кучу все это. Например, можно сделать пару доп.режимов кроме mode dst,src - mode prio & mark. А в /proc кроме(или вместо) адресов - prio:MIN (или MAJ+MIN) или mark:XXXX. Это бы позволило при желании вынести логику раскидывания по полосам за пределы xt_ratelimit, и уже извращаться там как душа пожелает: различать, например, не только адреса, но и протоколы, порты, да что угодно, вешая метки через CLASSIFY и MARK. Плюс в таком режиме и самому модулю, наверное, проще будет: не нужно сначала парсить адреса в правиле, загонять в хэш, а потом по хэшу сверять пролетащие пакеты. Тут просто по сути номер правила сравнивается с определенным полем в skb.

А как обстоят дела с внедрением поддержки префиксов?

Попробовал транк - та же беда. Гента - unstable или stable? Можно увидеть emerge --info? Unstable. Там вывод большой, могу на мыло. Я, правда, ебилд правил под себя когда-то, особенно в части сборки ядреных модулей.

У меня тоже самое, это если собирать версию из git. При этом релизный 1.10.0 собирается без проблем. accel-cmd -V accel-cmd 343af33b08ebc83791fd57a1ccdef91ce1ac2a9e т.е. последний коммит из мастер ветки. Тоже Gentoo, ядро 4.3, все собирается, в т.ч новый vlan_mon модуль.