voron

Не хватало мне для домашнего применения -m ADDRTYPE, -j NOTRACK в nftables. Много еще чего для кого-то нужного нет судя по http://wiki.nftables...ared_to_xtables Неясен вопрос одновременного использования с iptables/ip6tables, которое необходимо из-за отсутствия нужных матчей/таргетов. Указание стандартных приоритетов iptables'овских цепочек в http://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains не сильно помогает.

2micho Речь о просмотре BD без скачивания на устройство просмотра/декодирования.

то есть свежее ядро и полисеры в ingress с хэш-таблицами - и вот оно счастье для тех, у кого тарифы не слишком низкие, чтобы с полисером можно было жить. А для равномерного распределения нагрузки между RX-очередями(если она вдруг неравномерно распределяется), можно и ntuples использовать.

он уходит в железо скорее всего. Та же mqprio работает с аппаратным director'ом по очередям на основе skb priority. Видимо все программные механизмы будут давать блокировку. а если iptables'ами выставлять QoS и потом mqprio ? В древней доке почему-то приведен кривой пример с фильтром на mqprio, у меня фильтр не ложится на mqprio.

тогда вся надежда на настройку аппаратного интелового flow director так чтобы трафик одного клиента попадал всегда в одну и ту же очередь. Правда flow director работает на прием, а не на передачу. Но суть его как я понимаю- отправлять с той же очереди(с того же ядра) с которой пакет получен. То есть ручные правила применяться должны и на rx и на tx. Хотя может и применяются только на rx, а tx просто берет номер очереди из "flow track". Это если одна сетевка на все про все.

похоже управлять рассовыванием можно только в multiq. Вы пробовали multiq сразу вместе с пачкой фильтров с queue_mapping ? Статистика tc что показывает? Версия iproute2 соответствует версии ядра?Вот что у меня с multiq и без фильтров [root@ ~]# ./tc q d dev p4p1 root; ./tc q a dev p4p1 root handle 1: multiq [root@ ~]# ./tc q s dev p4p1 qdisc multiq 1: root refcnt 65 bands 24/64 [root@ ~]# for i in `seq 1 16` ; do ./tc qdisc add dev p4p1 parent 1:$i handle 1${i}: htb;done [root@ ~]# ./tc q s dev p4p1 qdisc multiq 1: root refcnt 65 bands 24/64 qdisc htb 11: parent 1:1 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 12: parent 1:2 r2q 10 default 0 direct_packets_stat 4043 direct_qlen 1000 qdisc htb 13: parent 1:3 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 14: parent 1:4 r2q 10 default 0 direct_packets_stat 170 direct_qlen 1000 qdisc htb 15: parent 1:5 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 16: parent 1:6 r2q 10 default 0 direct_packets_stat 1170 direct_qlen 1000 qdisc htb 17: parent 1:7 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 18: parent 1:8 r2q 10 default 0 direct_packets_stat 861 direct_qlen 1000 qdisc htb 19: parent 1:9 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 110: parent 1:10 r2q 10 default 0 direct_packets_stat 3414 direct_qlen 1000 qdisc htb 111: parent 1:11 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 112: parent 1:12 r2q 10 default 0 direct_packets_stat 276 direct_qlen 1000 qdisc htb 113: parent 1:13 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 114: parent 1:14 r2q 10 default 0 direct_packets_stat 1610 direct_qlen 1000 qdisc htb 115: parent 1:15 r2q 10 default 0 direct_packets_stat 1 direct_qlen 1000 qdisc htb 116: parent 1:16 r2q 10 default 0 direct_packets_stat 426 direct_qlen 1000 [root@ ~]# ./tc q s dev p4p1 qdisc multiq 1: root refcnt 65 bands 24/64 qdisc htb 11: parent 1:1 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 12: parent 1:2 r2q 10 default 0 direct_packets_stat 5685 direct_qlen 1000 qdisc htb 13: parent 1:3 r2q 10 default 0 direct_packets_stat 3 direct_qlen 1000 qdisc htb 14: parent 1:4 r2q 10 default 0 direct_packets_stat 497 direct_qlen 1000 qdisc htb 15: parent 1:5 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 16: parent 1:6 r2q 10 default 0 direct_packets_stat 3017 direct_qlen 1000 qdisc htb 17: parent 1:7 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 18: parent 1:8 r2q 10 default 0 direct_packets_stat 1270 direct_qlen 1000 qdisc htb 19: parent 1:9 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 110: parent 1:10 r2q 10 default 0 direct_packets_stat 5136 direct_qlen 1000 qdisc htb 111: parent 1:11 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 112: parent 1:12 r2q 10 default 0 direct_packets_stat 817 direct_qlen 1000 qdisc htb 113: parent 1:13 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 114: parent 1:14 r2q 10 default 0 direct_packets_stat 4229 direct_qlen 1000 qdisc htb 115: parent 1:15 r2q 10 default 0 direct_packets_stat 1 direct_qlen 1000 qdisc htb 116: parent 1:16 r2q 10 default 0 direct_packets_stat 771 direct_qlen 1000 [root@ ~]# То есть пакеты без фильтров тоже распределяются по очередям. А у вас при распределении по очередям нагрузка не распределяется по ядрам?

как минимум нужно добавить фильтр(ы) на корневой mq для привязки трафика клиентов к очередям, иначе трафик одного клиента может шейпиться во всех очередях с суммированием скорости.

Так ушел я от raw_spin_lock - в последних тестах он уже на уровне 5%.а не кажется ли вам, что просто занят топ idle poll'ами cpu_startup_entry и raw_spin_lock никуда не делся ? http://comments.gman....network/289937 не пробовали? С корневым qdisc mq и фильтрами с action skbedit queue_mapping на нем. RSS это scaling на прием, разве у вас HTB на входе интерфейса?

Может кто-то предоставить доступ к дампу ? Или кто-то уже выкладывает в открытый доступ? С http://reestr.rublacklist.net с выдачей в json мне работать неудобно

perf top? Как вообще ваши X520 переносят входящий PPS в районе 1-2M?

Хоть тема и старая, но не очень :) у меня это были ksoftirqd в топе. Источник - входящий pps. 4 ksoftirqd висят в топе и тормозят всё и сами себя, карта теряет пакеты. По результатам perf top -> _raw_spin_lock_irqsave и гугля набрел на тред мейлилиста e1000, где человеку посоветовали выключить IOMMU. Ребутнулся с параметром ядра iommu=off - помогло. Из хинтов intel'а - включение ntuple filters через ethtool для аппаратного распределения трафика между очередями.

и что - отличаются? :) Или это вопрос из разряда "Как звали Карла Маркса?"

Теперь это стало возможно

Кто-то rb912 прошивал в wrt?