[voron]

Не совсем понял, решает ли проблему с локами вариант с несколькими независимыми htb-деревьями поверх mq, который предложил Eric Dumazet?

for ETH in eth0
do
 tc qdisc del dev $ETH root 2>/dev/null

 tc qdisc add dev $ETH root handle 100: mq
 for i in `seq 1 4`
 do
   tc qdisc add dev $ETH parent 100:$i handle $i htb default 1
 done
done

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

Изменено 16 июля, 2015 пользователем voron

[tartila]

Не совсем понял, решает ли проблему с локами вариант с несколькими независимыми htb-деревьями поверх mq, который предложил Eric Dumazet?

for ETH in eth0
do
 tc qdisc del dev $ETH root 2>/dev/null

 tc qdisc add dev $ETH root handle 100: mq
 for i in `seq 1 4`
 do
   tc qdisc add dev $ETH parent 100:$i handle $i htb default 1
 done
done

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

 

Господа, поделюсь свежими новостями. Дисциплина mq действительно творит чудеса! Все становится просто великолепно, но есть одно НО... :) В предложенном диалоге с Эриком Думазетом человек использует дисциплину multiq и с ней же использует skbedit queue_mapping. Я попробовал использовать multiq, он не дал ожидаемого преимущества перед одним инстансом htb, как это получилось у mq. Случилось тоже самое, что и при одном дереве htb. А в mq - все OK, но с mq не работает queue_mapping :), tc пишет - Operation not permitted. Дело осталось за малым - рассовать ip строго по очередям. Но как?

[kayot]

IMHO вы какой-то ерундой страдаете. HTB параллелится(как и любые обработчики трафика в linux), аппаратный RSS нагрузку по ядрам распределяет ровненько.

Копать надо не в сторону распределения, а в сторону - почему загрузка растет.

 

Еще более IMHO - где-то в конфиге шейпера тупо не хватает размеров очередей(qdisc), и как только у вас растет нагрузка выше пары процентов начинается беда(трафик не успевает разливаться по классам).

[tartila]

IMHO вы какой-то ерундой страдаете. HTB параллелится(как и любые обработчики трафика в linux), аппаратный RSS нагрузку по ядрам распределяет ровненько.

Копать надо не в сторону распределения, а в сторону - почему загрузка растет.

 

Еще более IMHO - где-то в конфиге шейпера тупо не хватает размеров очередей(qdisc), и как только у вас растет нагрузка выше пары процентов начинается беда(трафик не успевает разливаться по классам).

 

Вы не правы, HTB имеет один общий лок на всю иерархию дерева. Распределение по ядрам в данном случае просто позволяет создать отдельные инстансы деревьев на удельный объем pps.

Плюс к этому загрузка у меня НЕ растет, как я отмечал в последних сообщениях, просто трафик встает колом внутри бриджа. Плюс mq решил проблему - трафик больше НЕ встает колом, но возникает пикантная ситуация, когда клиент получает bandwidth*queue_num без queue_mapping. :) Собственно, в чем и вопрос.

[photon]

По аналогии. Сделать несколько деревьев хэш-фильтров в соответствии с тем, как классы были поделены между деревьями HTB.

[tartila]

По аналогии. Сделать несколько деревьев хэш-фильтров в соответствии с тем, как классы были поделены между деревьями HTB.

 

Нее... Вы меня тоже не поняли. Смотрите, сделал на mq несколько деревьев HTB и все работает ЗАМЕЧАТЕЛЬНО. Только... Если у клиента rate limit, скажем, 5мбит/с и он ставит на закачку файл - он получает свои 5 Мбит. Ставит еще один файл и получает еще 5 Мбит. И т.д. Пока не заюзает все очереди в mq. В multiq это решается, как уже сказали, skbedit queue_mapping, например по первому октету клиента отправляем в первую очередь, если .0/28, во вторую очередь, если .16/28 и т.д. То есть, клиентов жестко приколачиваем к очередям multiq. А в mq это не получается - если я делаю filter action skbedit queue_mapping с parentid root qdisc mq, то в ответ получаю Operation not supported.

[tartila]

UP.

 

Не совсем понял, решает ли проблему с локами вариант с несколькими независимыми htb-деревьями поверх mq, который предложил Eric Dumazet?

for ETH in eth0
do
 tc qdisc del dev $ETH root 2>/dev/null

 tc qdisc add dev $ETH root handle 100: mq
 for i in `seq 1 4`
 do
   tc qdisc add dev $ETH parent 100:$i handle $i htb default 1
 done
done

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

 

Господа, поделюсь свежими новостями. Дисциплина mq действительно творит чудеса! Все становится просто великолепно, но есть одно НО... :) В предложенном диалоге с Эриком Думазетом человек использует дисциплину multiq и с ней же использует skbedit queue_mapping. Я попробовал использовать multiq, он не дал ожидаемого преимущества перед одним инстансом htb, как это получилось у mq. Случилось тоже самое, что и при одном дереве htb. А в mq - все OK, но с mq не работает queue_mapping :), tc пишет - Operation not permitted. Дело осталось за малым - рассовать ip строго по очередям. Но как?

[BETEPAH]

IMHO вы какой-то ерундой страдаете. HTB параллелится(как и любые обработчики трафика в linux), аппаратный RSS нагрузку по ядрам распределяет ровненько.

Копать надо не в сторону распределения, а в сторону - почему загрузка растет.

+1 столкнулся в своё время, что сам накосячил.

проверьте, у вас tc правильно настроен? http://www.opennet.ru/docs/RUS/LARTC/x1661.html

[tartila]

IMHO вы какой-то ерундой страдаете. HTB параллелится(как и любые обработчики трафика в linux), аппаратный RSS нагрузку по ядрам распределяет ровненько.

Копать надо не в сторону распределения, а в сторону - почему загрузка растет.

+1 столкнулся в своё время, что сам накосячил.

проверьте, у вас tc правильно настроен? http://www.opennet.ru/docs/RUS/LARTC/x1661.html

 

Ах, ну бросьте... До 2,5GBit/s все работает правильно, а потом начинаются проблемы? Хэши, конечно, есть. Гигабит у меня шейпится совершенно без нареканий, что на igb, что на ixgbe и два шейпится без проблем. :) Если вы делали шейпер на трафик >3 GBit (3-вход/3-выход GBit/s), то приветствую конструктивную критику.

[BETEPAH]

Да понятно, что хэши есть. Вопрос в том, правильно ли настроены? Просто у меня в данный момент, как раз в ЧНН нагрузка 2-2.5 достигает. Вернутся отпускники и не хотелось бы словить нежданчик в отпуске, в который завтра отъезжаю.

[tartila]

Да понятно, что хэши есть. Вопрос в том, правильно ли настроены? Просто у меня в данный момент, как раз в ЧНН нагрузка 2-2.5 достигает. Вернутся отпускники и не хотелось бы словить нежданчик в отпуске, в который завтра отъезжаю.

 

:))) Я вам гарантирую приятный сюрприз. Хотя в вашем случае, возможно, будет попроще... Вы же на bonding`е собираете? Там есть выбор очередей через /sys.

[BETEPAH]

Нет. Исключительно по 10G интерфейсу. Начитался на данном форуме про проблемы в бондинге.

[tartila]

Нет. Исключительно по 10G интерфейсу. Начитался на данном форуме про проблемы в бондинге.

 

Тогда можете оценить - как далеко вы от проблемы. Я использую ядро 3.18, здесь я на одном дереве HTB НЕ наблюдаю деградации пинга во время просадки шейпинга, clocksource=tsc, кол-во абонентов около 7k (загоняется в хэши), pps, при котором начинает деградировать скорость (по интерфейсу) 450kpps (вход), 400 kpps (выход).

[kayot]

И все же я уверен что узкое место где-то в конфигурации дерева, а не в локах и потоках.

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

 

Quantum увеличили, как на прошлой странице говорили? :)

[tartila]

И все же я уверен что узкое место где-то в конфигурации дерева

 

Ну естественно - это причина! Иначе бы от трафика бы и не зависело.

 

, а не в локах и потоках.

 

А это - следствие. У вас есть дерево иерархическое, которое необходимо обходить и некоторый поток данных. А также есть таймер, пускай будет tsc (clocksource), который определяет инертность фильтров в дисциплине (HTB). Так вот в какой-то момент разрешения таймера перестает хватать на это дерево и трафик. Хотя проца еще далеко полно.

 

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

 

Quantum увеличили, как на прошлой странице говорили? :)

 

Можно крутить очереди, quantum и прочее, увеличивая задержки в трубках HTB, и, отчасти, наверное это где-то решит проблему, но мне то надо получить правдивый мост с минимально вносимой задержкой, который нарезает большое кол-во трубок (7k) на большой трафик (>3GB/s).

 

Вы сами имели дело с такими шейперами или нет? :)

[tartila]

Еще раз апну тему. Еще раз вопрос - как всеже можно увести пакет в определенную аппаратную TX очередь? Условие - при создании корневого qdisc - mq, на него нельзя присоединить фильтры, соответственно нельзя сделать skbedit queue_mapping. Как еще это можно обойти?

[voron]

Я попробовал использовать multiq, он не дал ожидаемого преимущества перед одним инстансом htb, как это получилось у mq. Случилось тоже самое, что и при одном дереве htb. А в mq - все OK, но с mq не работает queue_mapping :), tc пишет - Operation not permitted. Дело осталось за малым - рассовать ip строго по очередям. Но как?

похоже управлять рассовыванием можно только в 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@ ~]#

То есть пакеты без фильтров тоже распределяются по очередям. А у вас при распределении по очередям нагрузка не распределяется по ядрам?

Изменено 31 июля, 2015 пользователем voron

[tartila]

Я попробовал использовать multiq, он не дал ожидаемого преимущества перед одним инстансом htb, как это получилось у mq. Случилось тоже самое, что и при одном дереве htb. А в mq - все OK, но с mq не работает queue_mapping :), tc пишет - Operation not permitted. Дело осталось за малым - рассовать ip строго по очередям. Но как?

похоже управлять рассовыванием можно только в multiq. Вы пробовали multiq сразу вместе с пачкой фильтров с queue_mapping ? Статистика tc что показывает? Версия iproute2 соответствует версии ядра?

 

У меня multiq не создает видимых очередей по количеству аппаратных, как это делает mq, просто вижу

./tc -s -d q s dev p4p1
qdisc multiq 1: root refcnt 65 bands 24/64 
Sent 38674147 bytes 25920 pkt (dropped 0, overlimits 0 requeues 0) 
backlog 0b 0p requeues 0

 

Да, пробовал, конечно. Иначе queue_mapping не сработает, если мне не изменяет память. John Fastabend из Intel, разраб mqprio подтвердил, что multiq имеет также лок и только mq и mqprio не имеют локов.

Короче, смысл работы таков, что надо понять, как обмануть коллбэк select_queue в ixgbe/igb. То есть, там есть какой то алгоритм по выбору TX очереди - скорее всего round robin, а требуется определить ручками - например, по маске. Я видел в инете упоминания о map-queue в iptables, но у меня такого нет. Видимо, требуется обновить iptables. Кто может подтвердить - работает ли эта фигулька?

Изменено 31 июля, 2015 пользователем tartila

[voron]

Да, пробовал, конечно. Иначе queue_mapping не сработает, если мне не изменяет память. John Fastabend из Inrel, разраб mqprio подтвердил, что multiq имеет также лок и только mq и mqprio не имеют локов.

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

 

Изменено 31 июля, 2015 пользователем voron

[BETEPAH]

Безумная идея возникла, а корневой класс случайно не ограничили на 2.5 ?

[BETEPAH]

Признаюсь, ступил, 100% загрузки при этом не должно быть.

[voron]

Короче, смысл работы таков, что надо понять, как обмануть коллбэк select_queue в ixgbe/igb. То есть, там есть какой то алгоритм по выбору TX очереди - скорее всего round robin, а требуется определить ручками - например, по маске.

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

Я видел в инете упоминания о map-queue в iptables, но у меня такого нет. Видимо, требуется обновить iptables. Кто может подтвердить - работает ли эта фигулька?

а если iptables'ами выставлять QoS и потом mqprio ? В древней доке почему-то приведен кривой пример с фильтром на mqprio, у меня фильтр не ложится на mqprio.

 

Изменено 31 июля, 2015 пользователем voron

[tartila]

Короче, смысл работы таков, что надо понять, как обмануть коллбэк select_queue в ixgbe/igb. То есть, там есть какой то алгоритм по выбору TX очереди - скорее всего round robin, а требуется определить ручками - например, по маске.

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

Я видел в инете упоминания о map-queue в iptables, но у меня такого нет. Видимо, требуется обновить iptables. Кто может подтвердить - работает ли эта фигулька?

а если iptables'ами выставлять QoS и потом mqprio ? В древней доке почему-то приведен кривой пример с фильтром на mqprio, у меня фильтр не ложится на mqprio.

 

У меня mqprio не запускается :), Fastabend забил на него, а он на некоторых сетевках не стартует :)))) Поэтому я не экспериментировал с ним. А вот как выбирается TX очередь - это загадка. Буду в понедельник копать.

[photon]

Т.е. ситуация такая: нужно либо убирать локи из multiq, либо добавить в mq возможность повесить фильтр с action skbedit queue_mapping. Иного выхода, как допилить самому или обращаться к разработчикам я не вижу. В той рассылке появлялся некто John Fastabend, скорее всего он за это и отвечает. Вот тут человек что-то пытается сделать с помощью ipset: http://www.spinics.net/lists/netdev/msg318787.html . Попробуйте полисеры для разнообразия, они хоть и менее качественно нарезают, но работают без глобального лока, в отличие от HTB.

Изменено 31 июля, 2015 пользователем photon

[NiTr0]

нужно либо убирать локи из multiq, либо добавить в mq возможность повесить фильтр с action skbedit queue_mapping

либо перепилить htb - идея здесь: http://www.ijcset.com/docs/IJCSET13-04-04-113.pdf (возможно, это будет проще).