[Alex/AT]

В общем и целом была банальная типовая конфигурация, никакого специфичного тюнинга (пример транслировал с кода).
sfq или pfifo, hfsc или htb - вопрос был открытый, при тестировании остановился на hfsc/sfq.
На выходных постараюсь синтетику погонять с этой конфигурацией vs htb на +/- непротухшем ядре, самих софтбрасов давно нет.

tc qdisc del dev eth0 root 
tc qdisc add dev eth0 root handle 1: hfsc default efff
tc class add dev eth0 parent 1: classid 1:efff hfsc sc rate 10gbit
tc qdisc add dev eth0 parent 1:efff handle efff: sfq

tc class replace dev eth0 parent 1: classid 1:1100 hfsc sc rate 10mbit ul rate 10mbit
tc class replace dev eth0 parent 1: classid 1:1200 hfsc sc rate 10mbit ul rate 10mbit
tc class replace dev eth0 parent 1: classid 1:1300 hfsc sc rate 10mbit ul rate 10mbit
...

tc class replace dev eth0 parent 1:1100 classid 1:1101 hfsc sc rate 1mbit ul rate 1mbit
tc class replace dev eth0 parent 1:1200 classid 1:1201 hfsc sc rate 2mbit ul rate 2mbit
tc class replace dev eth0 parent 1:1300 classid 1:1301 hfsc sc rate 3mbit ul rate 3mbit
tc class replace dev eth0 parent 1:1100 classid 1:1102 hfsc sc rate 2mbit ul rate 2mbit
tc class replace dev eth0 parent 1:1200 classid 1:1202 hfsc sc rate 5mbit ul rate 5mbit
tc class replace dev eth0 parent 1:1300 classid 1:1302 hfsc sc rate 4mbit ul rate 4mbit
...

tc qdisc replace dev eth0 parent 1:1101 handle 1101: sfq
tc qdisc replace dev eth0 parent 1:1201 handle 1201: sfq
tc qdisc replace dev eth0 parent 1:1301 handle 1301: sfq
tc qdisc replace dev eth0 parent 1:1101 handle 1102: sfq
tc qdisc replace dev eth0 parent 1:1201 handle 1202: sfq
tc qdisc replace dev eth0 parent 1:1301 handle 1302: sfq
...

[Pavel.M.A]

1 час назад, Alex/AT сказал:

А можно вопрос - зачем добавляете est / umax / dmax? С заданием только sc rate / ul rate ныне есть проблемы?

vasya_petrovich

Секунду, вытаскиваю из старого кода. На выходных погоняю синтетику и напишу, есть ли разница с HTB на свежих ядрах. У меня в конфигурации использовалось огромное число классов - например на входных интерфейсах класс на сессию/сервис.

Ну, для понимания, из чего дёргаю:

        $this->asg->nq->tc_enqueue('class', 'replace', $session->params['alloc']['ingress']['dev'],
            'parent 1: classid 1:'.dechex($session->params['alloc']['ingress']['bcc']).' hfsc',
            isset($session->params['in_rate']) ?
             ('sc rate '.$session->params['in_rate'].' ul rate '.$session->params['in_rate']) :
             'sc rate 10gbit');
        $this->asg->nq->tc_enqueue('class', 'replace', $session->params['alloc']['egress']['dev'],
            ' parent 1: classid 1:'.dechex($session->params['alloc']['egress']['bcc']).' hfsc',
            isset($session->params['out_rate']) ?
             ('sc rate '.$session->params['out_rate'].' ul rate '.$session->params['out_rate']) :
             'sc rate 10gbit');

Спасибо за пример, понял, а какие примерно нагрузки пережёвывали эти правила ?

[Alex/AT]

Гонял на 2xX5650/4x82576/2.6.32+ PPPoE(1700+ses)/conntrack/filter/SNAT/DNAT/tc-hfsc. softRPS вдогонку к аппаратным очередям.

 

tc - root qdisc как раз hfsc, с несколькими классами на юзера (in/out сеанса, и на каждый сервис in/out), плюс фильтры с активным юзанием IFB. Листья - sfq.

Ну то есть к чему я это: классов hfsc с субклассами на IFB висело порядка тысяч так 6-8, sfq на листьях примерно на 3-4 тысячи меньше.

 

HTB на этих системах вёл себя из рук вон, может из-за числа классов, может ещё из-за чего. Точно были проблемы с локами, и ещё c квантом при большой разнице в субклассах.

PFIFO тоже по какой-то причине был во время тестирования выкинут, насколько помню, причиной были как раз нагрузка + результирующая пилообразная характеристика трафика.
Не спорю, что конфигурация очень специфичная. Вполне возможно, что HFSC лососнёт у HTB при числе классов <100 или сколько там. Надо синтетику гонять.
 

Ниже нагрузка в описанной конфигурации при примерно 2/2 гигах (расчётно до 4/4), ~300kpps (расчётно до 600) в каждую сторону, при среднем размере пакета в ~800 байт.

На современных ядрах, процах и картах наверняка можно куда больше протащить.

Tasks: 2142 total,   3 running, 2139 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.6%us,  2.9%sy,  0.0%ni, 66.8%id,  0.0%wa,  0.0%hi, 29.7%si,  0.0%st
Cpu1  :  5.1%us,  6.1%sy,  0.0%ni, 58.7%id,  0.0%wa,  0.0%hi, 30.1%si,  0.0%st
Cpu2  :  4.8%us,  3.5%sy,  0.0%ni, 74.6%id,  0.0%wa,  0.0%hi, 17.1%si,  0.0%st
Cpu3  :  1.3%us, 14.4%sy,  0.0%ni, 67.9%id,  0.0%wa,  0.0%hi, 16.3%si,  0.0%st
Cpu4  :  1.6%us, 17.9%sy,  0.0%ni, 62.9%id,  0.0%wa,  0.0%hi, 17.6%si,  0.0%st
Cpu5  :  1.0%us,  1.0%sy,  0.0%ni, 88.7%id,  0.0%wa,  0.0%hi,  9.3%si,  0.0%st
Cpu6  :  0.3%us,  0.6%sy,  0.0%ni, 54.8%id,  2.9%wa,  2.6%hi, 38.7%si,  0.0%st
Cpu7  :  1.9%us,  3.5%sy,  0.0%ni, 64.1%id,  0.0%wa,  1.6%hi, 28.8%si,  0.0%st
Cpu8  :  2.6%us, 11.9%sy,  0.0%ni, 69.1%id,  0.0%wa,  1.3%hi, 15.1%si,  0.0%st
Cpu9  :  2.7%us, 11.8%sy,  0.0%ni, 61.9%id,  0.0%wa,  0.6%hi, 23.0%si,  0.0%st
Cpu10 :  0.6%us, 13.8%sy,  0.0%ni, 63.5%id,  0.0%wa,  0.3%hi, 21.7%si,  0.0%st
Cpu11 :  0.0%us,  0.0%sy,  0.0%ni, 88.9%id,  0.0%wa,  1.0%hi, 10.2%si,  0.0%st
Mem:   8183116k total,  2407612k used,  5775504k free,   141976k buffers
Swap:  8387568k total,        0k used,  8387568k free,   370244k cached

 

Вот ещё снимок с того же софта с 150kpps (гиг на гиг) и ~600 сессий (соответственно классов тысячи под три, листьев под тысячу-полторы) на каком-то Core 2 Quad с двумя совсем печальными одноочередными bnx2 :)

На этом был нелинейный рост нагрузки (видимо, из-за карт), уже на ~1.2-1.3 гига ресурсов проца не оставалось. Именно оттуда осталось и отношение к bnx2 (5709 включая).

Tasks: 811 total,   2 running, 809 sleeping,   0 stopped,   0 zombie
Cpu0  :  1.3%us, 12.7%sy,  0.0%ni, 54.6%id,  0.0%wa,  0.0%hi, 31.4%si,  0.0%st
Cpu1  :  0.6%us,  1.6%sy,  0.0%ni, 60.1%id,  0.0%wa,  0.0%hi, 37.7%si,  0.0%st
Cpu2  :  0.3%us,  1.0%sy,  0.0%ni, 53.1%id,  0.0%wa,  0.0%hi, 45.6%si,  0.0%st
Cpu3  :  1.6%us,  4.9%sy,  0.0%ni, 58.6%id,  0.0%wa,  0.3%hi, 34.6%si,  0.0%st
Mem:   2053144k total,  1487484k used,   565660k free,   140500k buffers
Swap:  2096472k total,     2144k used,  2094328k free,   490332k cached

P.S. Уже года три как не занимаюсь занимательной софтовой брасологией и бордерологией, поэтому мог отстать от жизни.

[vasya_petrovich]

Бред какой-то с hfsc.
Тестировал у себя на локальной машине.

Создал пару классов. Через какое-то время трафик до некоторых IP адресов перестает ходить, стоит только удалить рут и сразу все нормально начинает работать.

Схему собираю следующим образом:

Цитата

tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: hfsc default 10
tc class add dev eth0 parent 1: classid 1:10 hfsc sc rate 20mbit

tc class add dev eth0 parent 1:10 classid 1:100 hfsc sc rate 10mbit ul rate 10mbit

iptables -t mangle -A OUTPUT -o eth0 -j CLASSIFY --set-class 1:100

Если дефолтный класс не указать, так вообще сразу трафик затыкается.

Пробовал очередь навешивать на краевой класс pfifo, всеравно блокируется через какое-то время.

 

Цитата

tc qdisc add dev eth0 parent 1:100 pfifo limit 100

 

[nuclearcat]

Дефолтный - обязательно. Особенность hfsc.

И не забудьте чтоб он захватывал и arp на интерфейсе.

[vasya_petrovich]

А arp ему зачем?

[vasya_petrovich]

В 23.10.2017 в 16:34, vasya_petrovich сказал:

Создал пару классов. Через какое-то время трафик до некоторых IP адресов перестает ходить, стоит только удалить рут и сразу все нормально начинает работать.

Нашел причину блокировки.
Если в краевых классах родителем указывать дефолтный класс, то трафик через какое-то время начинает "шалить", блокироваться и т.д.

Сейчас тестирую следующую схему:

Цитата

tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: hfsc default 10

tc class add dev eth0 parent 1: classid 1:1 hfsc sc rate 100mbit ul rate 100mbit
tc class add dev eth0 parent 1:1 classid 1:10 hfsc sc rate 20mbit

tc class add dev eth0 parent 1:1 classid 1:100 hfsc sc rate 10mbit ul rate 10mbit

iptables -t mangle -A OUTPUT -o eth0 -j CLASSIFY --set-class 1:100

 

[vasya_petrovich]

Нашлось решение вопроса :)

 

Нет, я не выкинул на свалку ничего...
Оказывается, все проще простого, достаточно было навесить mq на сетевую карту и на каждую очередь навесить фильтры с action mirred egress redirect dev ifbX
Нагрузка сразу же упала и дышать стало намного легче.

[Walther19]

В 10.11.2017 в 11:52, vasya_petrovich сказал:

Нашлось решение вопроса :)

 

Нет, я не выкинул на свалку ничего...
Оказывается, все проще простого, достаточно было навесить mq на сетевую карту и на каждую очередь навесить фильтры с action mirred egress redirect dev ifbX
Нагрузка сразу же упала и дышать стало намного легче.

А можно, пожалуйста поподробнее. Что вы имели ввиду под mq на интерфейс? tc qdisc add dev ens1f0 root handle 1: multiq? Или я неправильно понял? Изначально шла речь про hfsc и неясно как быть тогда с tc qdisc add dev eth0 root handle 1: hfsc default 10.

 

[vasya_petrovich]

Под mq имелось ввиду именно mq, не multiq.

 

Hfsc предлагалось использовать, как альтернативу htb, т.к. предполагалось, что из-за него (htb) растет нагрузка native_queued_spinlock.

[kayot]

vasya_petrovich 

Кусок конфига в студию, если не сложно.

[vasya_petrovich]

Цитата

tc qdisc add dev eth0 handle 1: root mq

 

tc qdisc add dev eth0 parent 1:1 handle 8001 htb

tc filter add dev eth0 parent 8001: u32 match u32 0 0 action mirred egress redirect dev ifb0

 

tc qdisc add dev eth0 parent 1:2 handle 8002 htb

tc filter add dev eth0 parent 8002: u32 match u32 0 0 action mirred egress redirect dev ifb0

 

tc qdisc add dev eth0 parent 1:3 handle 8003 htb

tc filter add dev eth0 parent 8003: u32 match u32 0 0 action mirred egress redirect dev ifb0

 

tc qdisc add dev eth0 parent 1:4 handle 8004 htb

tc filter add dev eth0 parent 8004: u32 match u32 0 0 action mirred egress redirect dev ifb0

В данном примере я с каждой tx очереди сетевой карты делаю редирект на ifb0.

И на ifb0 нарезаю как мне надо исходящий трафик.

[k0ste]

vasya_petrovich , если fq_codel вместо mq поставить, как оно будет? Чисто ради интереса вопрос, раз уж есть на чем потестить.