Перейти к содержимому
Калькуляторы

Linux Embedded Appliance Framework aka LEAF Линуксовый "модульный" софтроутер

заглянул в пакет bird.lrp а в нем только IPv6 версия (( да и не последняя.

bird - он при включении ipv6 именуется bird6, подходит для обеих протоколов. Хотя в реальных условиях я его не тестировал.

Версию обновил, в бете2 будет свежая.

 

http://bird.network.cz/?get_doc&f=bird-1.html#ss1.2

 

BIRD supports either IPv4 or IPv6 protocol, but have to be compiled separately for each one. Therefore, a dualstack router would run two instances of BIRD (one for IPv4 and one for IPv6), with completely separate setups (configuration files, tools ...).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поправил bird, собрал тестовый срез 5.0 ветки с исправлениями, желающие проверить - могут стянуть отсюда. Проблем наблюдаться не должно, а вот утечки памяти ядра (предположительно - где-то в сетевой подсистеме при создании/удалении маршрутов) - таки исчезли (то ли в связи с апдейтом ядра, то ли с включением дебага - т.к. в 3.2.6 или 3.2.12-13 еще были, после обновления до 3.2.19 и включения kmemleak внезапно испарились)

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

to NiTr0

 

1. После внесения изменений в скрипт init и перепаковки LEAF запустился.

2. Расскоментарил /etc/inetd.conf строчки с ssh www

Добавил в файл /etc/hosts.allow

ALL: 10.16.1.0/255.255.255.0

сохранил конфиг, перезапустил сервер. но в логах dmesg DROPы

[ 85.966269] Shorewall:net2fw:DROP:IN=eth0 OUT= MAC=00:30:48:33:81:b2:00:15:17:bd:83:b9:08:00 SRC=10.16.1.10 DST=10.16.1.78 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1184 DF PROTO=TCP SPT=56288 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

[ 88.965292] Shorewall:net2fw:DROP:IN=eth0 OUT= MAC=00:30:48:33:81:b2:00:15:17:bd:83:b9:08:00 SRC=10.16.1.10 DST=10.16.1.78 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1185 DF PROTO=TCP SPT=56288 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

[ 94.964607] Shorewall:net2fw:DROP:IN=eth0 OUT= MAC=00:30:48:33:81:b2:00:15:17:bd:83:b9:08:00 SRC=10.16.1.10 DST=10.16.1.78 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1186 DF PROTO=TCP SPT=56288 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

[ 236.635660] Shorewall:net2fw:DROP:IN=eth0 OUT= MAC=00:30:48:33:81:b2:00:15:17:bd:83:b9:08:00 SRC=10.16.1.10 DST=10.16.1.78 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=43614 DF PROTO=TCP SPT=56352 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

[ 239.633934] Shorewall:net2fw:DROP:IN=eth0 OUT= MAC=00:30:48:33:81:b2:00:15:17:bd:83:b9:08:00 SRC=10.16.1.10 DST=10.16.1.78 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=43615 DF PROTO=TCP SPT=56352 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

Остановил iptables, зашел.

 

3. В сервере установлена карточка intel

06:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

06:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

 

однако при загрузке LEAF в частности модуля igb ошибки в dmesg

[ 8.153185] igb: Unknown symbol dca_remove_requester (err 0)

[ 8.154489] igb: Unknown symbol dca_add_requester (err 0)

[ 8.155134] igb: Unknown symbol dca_remove_requester (err 0)

[ 8.157050] igb: Unknown symbol dca_unregister_notify (err 0)

[ 8.157316] igb: Unknown symbol dca_register_notify (err 0)

[ 8.157721] igb: Unknown symbol dca3_get_tag (err 0)

[ 8.158646] igb: Unknown symbol dca_add_requester (err 0)

[ 8.159289] igb: Unknown symbol dca_unregister_notify (err 0)

[ 8.159517] igb: Unknown symbol dca_register_notify (err 0)

[ 8.159775] igb: Unknown symbol dca3_get_tag (err 0)

 

Гружу с консоли

firewall# modprobe igb

modprobe: can't load module igb (igb.ko): unknown symbol in module, or unknown parameter

firewall#

 

Параллельно на этом же самом сервере тестирую CentOS6.2 c драйвером igb version: 3.4.7 все ок.

http://forum.nag.ru/forum/index.php?showtopic=46335&st=560

 

Почему не грузится ? Какой версии модуль?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поправил bird, собрал тестовый срез 5.0 ветки с исправлениями, желающие проверить - могут стянуть отсюда. Проблем наблюдаться не должно, а вот утечки памяти ядра (предположительно - где-то в сетевой подсистеме при создании/удалении маршрутов) - таки исчезли (то ли в связи с апдейтом ядра, то ли с включением дебага - т.к. в 3.2.6 или 3.2.12-13 еще были, после обновления до 3.2.19 и включения kmemleak внезапно испарились)

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

 

Загрузился.

Хотел проверить в новой сборке igb модуль

но рутом с пустым паролем не пускает, - возможно из за того что поверх старой версии распаковал новую

Изменено пользователем QWE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

охранил конфиг, перезапустил сервер. но в логах dmesg DROPы

shorewall конфигурить надо, и он конфигурится никак не в inetd и не в hosts.allow. Не хотите с ним возиться - отключите, юзайте голый иптейблс.

 

однако при загрузке LEAF в частности модуля igb ошибки в dmesg

Модуль dca имеется? Вообще для разрешения подобных проблем и предусмотрена автоматическая подгрузка нужных модулей в меню...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

перенес все тесты из http://forum.nag.ru/forum/index.php?showtopic=46335&st=560 на LEAF

Сейчас летит в одну сторону 610к PPS и при этом ksoftirqd и в помине нет рядом.

Суммарно по top загрузки нет никакой, как то сомнительно.

cat /proc/interrupts показывает что в системе 23000х8(ядер)=184000 прерываний в секунду. В моих тестах драйвер igb по умлочанию генерил 20000 прерываний в сек. ТОже непонтяно много это или мало.

Прерывания одной очереди интерфейса ровно размазаны по всем процам.

Только также как в моих прошлых тестах несмотря на наличие 8 очередей TxRx на каждом интерфейсе,но прерывания генерит только одна очередь. Скорее это уже фича, а не бага.

 

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

PerfTop: 14 irqs/sec kernel:100.0% exact: 0.0% [1000Hz cycles], (all, 8 CPUs)

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

samples pcnt function DSO

_______ _____ ____________________ _________________

 

40.00 27.2% igb_alloc_rx_buffers [igb]

18.00 12.2% igb_xmit_frame_ring [igb]

15.00 10.2% _raw_spin_lock [kernel.kallsyms]

12.00 8.2% __alloc_skb [kernel.kallsyms]

9.00 6.1% vlan_gro_receive [kernel.kallsyms]

7.00 4.8% skb_release_data [kernel.kallsyms]

7.00 4.8% dev_queue_xmit [kernel.kallsyms]

5.00 3.4% ip_forward [kernel.kallsyms]

5.00 3.4% consume_skb [kernel.kallsyms]

5.00 3.4% skb_gro_reset_offset [kernel.kallsyms]

 

Удивился вобщем результатами. Хочется нагнать еще трафика - но мощности тестилок нехватает )) ((

 

при помощи утилиты apkg установил пакеты с флешки, зашел в lrcfg сохранился, затем ребутнулся. Пакетов нет((

Изменено пользователем QWE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Суммарно по top загрузки нет никакой, как то сомнительно.

%hi %si %sy смотрите, должно немного присутствовать. Это с нетфлоу или без?

 

А по поводу очередей - странно конечно. Как вариант - заюзать RPS/RFS (хотя от второго толку не сильно много)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Суммарно по top загрузки нет никакой, как то сомнительно.

%hi %si %sy смотрите, должно немного присутствовать. Это с нетфлоу или без?

 

А по поводу очередей - странно конечно. Как вариант - заюзать RPS/RFS (хотя от второго толку не сильно много)

 

Загрузил модуль NETFLOW

top

Mem: 58632K used, 16574476K free, 0K shrd, 3864K buff, 16720K cached

CPU0: 0.0% usr 0.0% sys 0.0% nic 87.8% idle 0.0% io 0.0% irq 12.2% sirq

CPU1: 0.1% usr 0.0% sys 0.0% nic 91.2% idle 0.0% io 0.0% irq 8.5% sirq

CPU2: 0.0% usr 0.0% sys 0.0% nic 83.7% idle 0.0% io 0.0% irq 16.2% sirq

CPU3: 0.0% usr 0.0% sys 0.0% nic 84.1% idle 0.0% io 0.0% irq 15.8% sirq

CPU4: 0.0% usr 0.0% sys 0.0% nic 92.2% idle 0.0% io 0.0% irq 7.7% sirq

CPU5: 0.0% usr 0.0% sys 0.0% nic 89.1% idle 0.0% io 0.0% irq 10.8% sirq

CPU6: 0.0% usr 0.1% sys 0.0% nic 87.3% idle 0.0% io 0.0% irq 12.4% sirq

CPU7: 0.0% usr 0.0% sys 0.0% nic 92.5% idle 0.0% io 0.0% irq 7.5% sirq

 

testrouter# sar -n DEV 1

Linux 2.6.35.14-i686 (testrouter) 06/18/12 _i686_ (8 CPU)

 

19:54:29 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s

19:54:30 lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00

19:54:30 ifb0 0.00 0.00 0.00 0.00 0.00 0.00 0.00

19:54:30 ifb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00

19:54:30 eth0 1.00 0.00 0.06 0.00 0.00 0.00 0.00

19:54:30 eth1 0.00 0.00 0.00 0.00 0.00 0.00 0.00

19:54:30 eth2 616361.00 0.00 63802.99 0.00 0.00 0.00 0.00

19:54:30 eth3 0.00 616353.00 0.00 63802.17 0.00 0.00 0.00

19:54:30 eth2.560 616360.00 0.00 55376.09 0.00 0.00 0.00 0.00

19:54:30 eth3.560 0.00 616361.00 0.00 63802.99 0.00 0.00 0.00

 

если чуть поддашь газу (>616kPPS) то сразу ksoftirqd 100% и потери

выгружаю модуль NETFLOW, система отдыхает

Mem: 58996K used, 16574112K free, 0K shrd, 3864K buff, 16724K cached

CPU0: 0.0% usr 0.0% sys 0.0% nic 100% idle 0.0% io 0.0% irq 0.0% sirq

CPU1: 0.0% usr 0.0% sys 0.0% nic 99.7% idle 0.0% io 0.0% irq 0.2% sirq

CPU2: 0.0% usr 0.0% sys 0.0% nic 100% idle 0.0% io 0.0% irq 0.0% sirq

CPU3: 0.0% usr 0.0% sys 0.0% nic 100% idle 0.0% io 0.0% irq 0.0% sirq

CPU4: 0.0% usr 0.0% sys 0.0% nic 99.8% idle 0.0% io 0.0% irq 0.1% sirq

CPU5: 0.0% usr 0.0% sys 0.0% nic 99.7% idle 0.0% io 0.0% irq 0.2% sirq

CPU6: 0.0% usr 0.0% sys 0.0% nic 100% idle 0.0% io 0.0% irq 0.0% sirq

CPU7: 0.0% usr 0.0% sys 0.0% nic 100% idle 0.0% io 0.0% irq 0.0% sirq

 

делаю вывод ipt_NETFLOW добавляет к загрузке более чем 15%

 

А что значит заюзать RPS? гружу igb RSS=0,0 и на каждом интерфейсе по 8 очередей TxRx, но прерывания генерит только одна очередь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

делаю вывод ipt_NETFLOW добавляет к загрузке более чем 15%

Возможно, упирается в процессорную шину все, раз так резко загрузка подскакивает. Все-таки обе головы висят на одной шине и делят ее между своими ядрами... Если это так - то распараллеливание ничего особо не даст.

 

А что значит заюзать RPS?

http://forum.nag.ru/forum/index.php?showtopic=59217

Вполне неплохая вещь...

 

гружу igb RSS=0,0

А чего не 8,8? 0,0 - вроде как отключение очередей же.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А чего не 8,8? 0,0 - вроде как отключение очередей же.

 

Одинаково создаются и в том и друом случае по 8TxRx на каждый интерфейс. 0,0 это типа драйвер сам решает сколько делать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

http://forum.nag.ru/...showtopic=59217

Вполне неплохая вещь...

 

Почитал по теме.

Как понимаю из http://lwn.net/Articles/328339/ существует проблема с драйверами у которых есть NAPI и у этих сетевух одна очередь.

В моем случае у чипа 82576 много очередей, причем очередей больше чем ядер.

testrouter# ls -1 /sys/class/net/eth2/queues/

rx-0

rx-1

rx-10

rx-11

rx-12

rx-13

rx-14

rx-15

rx-2

rx-3

rx-4

rx-5

rx-6

rx-7

rx-8

rx-9

 

Я правильно понимаю в моем случае нужно загрузить драйвер сетевой с одной очередью RSS, активировать RPS для интерфейса и 16 очередей интерфейса eth2 rx-ХХ привязать по две к 8 ядрам?

У меня на самом деле на интерфейсах есть VLANы, делать тоже самое для них на соответствующем интерфейсе?

 

Загрузил драйвер modprobe igb QueuePairs=0,0 RSS=4,4

теперь получается так что одна очередь RX генерит прерывания и они разбросаны по разным ядрам

71: 49 44 47 44 51 40 48 56 PCI-MSI-edge eth2-rx-0

72: 1 1 0 1 0 1 0 1 PCI-MSI-edge ioat-msi

74: 47 38 47 53 46 42 44 46 PCI-MSI-edge eth2-rx-1

75: 103589 104493 100423 100329 101954 102444 101295 101420 PCI-MSI-edge eth2-rx-2

76: 47 54 40 45 41 47 42 47 PCI-MSI-edge eth2-rx-3

77: 41 47 42 47 40 45 54 47 PCI-MSI-edge eth2-tx-0

78: 40 45 54 48 42 47 48 41 PCI-MSI-edge eth2-tx-1

79: 43 48 50 41 56 50 47 44 PCI-MSI-edge eth2-tx-2

80: 54 47 45 40 47 41 47 42 PCI-MSI-edge eth2-tx-3

81: 1 0 0 0 0 0 0 0 PCI-MSI-edge eth3

82: 51 39 52 54 50 35 46 51 PCI-MSI-edge eth3-rx-0

83: 50 33 44 49 50 54 36 48 PCI-MSI-edge eth3-rx-1

84: 50 54 37 48 44 50 33 50 PCI-MSI-edge eth3-rx-2

85: 44 49 33 50 36 48 54 50 PCI-MSI-edge eth3-rx-3

86: 36 50 56 51 33 48 47 43 PCI-MSI-edge eth3-tx-0

87: 787449 786522 790629 790719 789094 788620 789769 789601 PCI-MSI-edge eth3-tx-1

88: 41 42 56 37 55 54 55 38 PCI-MSI-edge eth3-tx-2

89: 51 54 52 38 52 36 40 41 PCI-MSI-edge eth3-tx-3

 

А вообще складывается такое ощущение что при любых параметрах загрузки igb принудительно включен RPS: Receive Packet Steering и балансировка прерываний по ядрам SMP_affinity автоматически работает через одно IRQ.

Изменено пользователем QWE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

0,0 это типа драйвер сам решает сколько делать.

Таки да, в мануале так; а вот сам драйвер отчего-то по modinfo говорил:

RSS:Number of Receive-Side Scaling Descriptor Queues (0-8), default 1=number of cpus

Видать, опечатка...

 

В моем случае у чипа 82576 много очередей, причем очередей больше чем ядер.

Вроде как по 8 на порт (интерфейс) в чипе... Может драйвер бредит конечно, кто его знает.

 

теперь получается так что одна очередь RX генерит прерывания и они разбросаны по разным ядрам

Это обычное поведение. Но только одно ядро в единицу времени обрабатывает прерывание. От того и прибивать прерывания к ядрам надо. Производительность выше будет, по сравнению со скачущим по ядрам обработчиком (cache misses и прочие прелести).

 

складывается такое ощущение что при любых параметрах загрузки igb принудительно включен RPS: Receive Packet Steering и балансировка прерываний по ядрам SMP_affinity автоматически работает через одно IRQ.

RPS - это несколько другое. Прерывание обрабатывается одним ядром, но данные потом раскидываются по обработчикам, привязанным к остальным ядрам.

 

В общем, на каждой очереди включите RPS на все ядра, очереди прибейте жестко к ядрам (1 очередь - 1 ядро), и посмотрите на результат.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В общем, на каждой очереди включите RPS на все ядра, очереди прибейте жестко к ядрам (1 очередь - 1 ядро), и посмотрите на результат.

 

Собственно это и есть проблема, как бы ни грузился драйвер (неважно какие очереди сдвоенные одинарные) - всегда загружена только одна очередь, которая соответственно висит на одном прерывании, но при этом равномерно загружены все процессоры от этого IRQ

testrouter# cat /proc/interrupts

CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7

70: 0 0 1 0 0 0 0 0 PCI-MSI-edge eth2

71: 318693 319055 306356 305497 312611 313464 311530 310903 PCI-MSI-edge eth2-rx-0 --- вот эта очередь на одном IRQ грузит все ядра

74: 343 356 340 375 369 375 392 363 PCI-MSI-edge eth2-rx-1

75: 375 381 389 373 351 379 362 347 PCI-MSI-edge eth2-tx-0

76: 341 375 361 342 386 362 373 373 PCI-MSI-edge eth2-tx-1

77: 0 0 0 0 1 0 0 0 PCI-MSI-edge eth3

78: 379 371 377 391 366 369 348 370 PCI-MSI-edge eth3-rx-0

79: 361 358 340 364 369 387 366 371 PCI-MSI-edge eth3-rx-1

80: 2486946 2486605 2499299 2500117 2493010 2492132 2494069 2494719 PCI-MSI-edge eth3-tx-0 --- и эта очередь на одном IRQ грузит все ядра

81: 351 359 378 358 358 371 384 357 PCI-MSI-edge eth3-tx-1

 

Я может непонимаю конечно как сделать вот это "В общем, на каждой очереди включите RPS на все ядра"...

 

По моей логике - как только есть несколько очередей на прием, то драйвер автоматом входящие пакеты распределяет равномерно в число организованных очередей, которые в свою очередь висят на разных прерываниях и те в свою очередь "прибиваются" к ядрам. Тогда вопрос простой с каким параметрами грузить igb чтобы это произошло?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Проблема драйвера/железа/чего там еще, на это скорее сего только разработчики повлияют...

 

но при этом равномерно загружены все процессоры от этого IRQ

В среднем - равномерно. В конкретный момент времени - только одно ядро работает, остальные гуляют.

 

Я может непонимаю конечно как сделать вот это "В общем, на каждой очереди включите RPS на все ядра"...

echo ffff > /sys/class/net/eth0/queues/rx-0/rps_cpus

и т.д. для каждой очереди.

 

По моей логике - как только есть несколько очередей на прием, то драйвер автоматом входящие пакеты распределяет равномерно в число организованных очередей, которые в свою очередь висят на разных прерываниях и те в свою очередь "прибиваются" к ядрам.

Распараллеливает пакеты даже не драйвер, а чип исходя из хеша src:dst IP/port (если не ошибаюсь). От того распараллеливания нет на PPPoE в частности. А вот почему нормального распараллеливания нет на обычном траффике - вопрос...

 

Тогда вопрос простой с каким параметрами грузить igb чтобы это произошло?

Что произошло? Прибивание к ядрам - так это из юзерленда рулится через smp_affinity. Распараллеливание - вроде драйвер/чип должен равномерно распараллеливать, почему не хочет - неведомо (можно попытаться тикет создать, может пофиксят когда-то).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

igb 2.1.9 если несколько раз подрял перезапускать iperf генератор то каждая новая попытка теста - наполняет другую(наименее загруженную) очередь. Но грузится одна очередь.

[root@testrouter src]# cat /proc/interrupts | grep -E "eth0-rx"

50: 13522 14096 14255 16992 15100 13534 14347 14157 PCI-MSI-edge eth0-rx-0

51: 10343 11278 10580 10787 11382 11064 10150 10844 PCI-MSI-edge eth0-rx-1

52: 10004 11133 9815 10826 10113 11973 10428 10378 PCI-MSI-edge eth0-rx-2

55: 2245 2396 2448 2335 2512 2355 2186 2306 PCI-MSI-edge eth0-rx-3

[root@testrouter src]#

 

igb 2.2.9

[root@testrouter src]# modprobe igb QueuePairs=0,0 RSS=4,4

[root@testrouter src]# cat /proc/interrupts | grep -E "eth0-rx"

50: 12980 17579 17096 15355 19795 16142 16372 13912 PCI-MSI-edge eth0-rx-0

51: 20220 28178 27591 24361 32331 26256 27262 22034 PCI-MSI-edge eth0-rx-1

52: 70 81 67 68 67 66 59 63 PCI-MSI-edge eth0-rx-2

55: 38 53 48 38 67 50 64 64 PCI-MSI-edge eth0-rx-3

[root@testrouter src]#

трафик раскладывается (хотя и не равномерно) по двум из 4 х очередей eth0, после перезапуска iperf генератора начинают заполняться снова две очереди, которые не заполнялись в прошлый раз

 

версии 2.3.4, 2.4.8, 2.4.11 , 3.2.10 , 3.3.6 ведут себя точно также как и 3.4.7 - хоть сколько раз перезапускай iperf все равно в одну очередь

 

Может быть порты не учавствуют при распределении трафика по очередям? в моих тестах src/dst IP всегда одинаковы. И пакеты будут раскладываться на реальном трафике...

Изменено пользователем QWE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

настроил роутер на тестовой версии LEAF

testrouter# uname -a

Linux testrouter 3.2.19-i686 #1 SMP Sun Jun 17 15:42:47 EEST 2012 i686 GNU/Linux

testrouter#

с модулем ipt_NETFLOW результат достигнут 542693 packets/sec

CPU0: 0.0% usr 0.0% sys 0.0% nic 94.6% idle 0.0% io 0.0% irq 5.3% sirq

CPU1: 0.0% usr 0.0% sys 0.0% nic 93.4% idle 0.0% io 0.0% irq 6.5% sirq

CPU2: 0.0% usr 0.0% sys 0.0% nic 90.6% idle 0.0% io 0.0% irq 9.3% sirq

CPU3: 0.0% usr 0.0% sys 0.0% nic 93.3% idle 0.0% io 0.0% irq 6.6% sirq

CPU4: 0.0% usr 0.0% sys 0.0% nic 94.8% idle 0.0% io 0.0% irq 5.1% sirq

CPU5: 0.0% usr 0.0% sys 0.0% nic 94.1% idle 0.0% io 0.0% irq 5.8% sirq

CPU6: 0.0% usr 0.0% sys 0.0% nic 92.9% idle 0.0% io 0.0% irq 7.0% sirq

CPU7: 0.0% usr 0.0% sys 0.0% nic 93.6% idle 0.0% io 0.0% irq 6.3% sirq

 

добавив + 20кPPS выскакивает softirq 100%

 

 

Не дотянула новая система 13% до результатов тестов LEAF 4.2.1_i686 616кPPS с загруженным модулем ipt_NETFLOW

 

 

PerfTop: 1067 irqs/sec kernel:99.9% exact: 0.0% [1000Hz cycles], (all, 8 CPUs)

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

11.50% [kernel] [k] __slab_free

6.87% [igb] [k] igb_xmit_frame_ring

5.54% [igb] [k] igb_alloc_rx_buffers

4.68% [kernel] [k] _raw_spin_lock

4.17% [ip_tables] [k] ipt_do_table

3.81% [kernel] [k] __alloc_skb

3.72% [kernel] [k] eth_type_trans

3.64% [kernel] [k] nommu_map_page

3.24% [kernel] [k] skb_release_data

3.16% [kernel] [k] check_addr

3.10% [kernel] [k] memcpy

3.09% [ipt_NETFLOW] [k] netflow_target

2.77% [kernel] [k] __kmalloc_track_caller

2.41% [kernel] [k] __netif_receive_skb

2.09% [kernel] [k] __netdev_alloc_skb

1.97% [kernel] [k] dev_queue_xmit

1.40% [kernel] [k] ip_route_input_common

1.35% [kernel] [k] setup_object.isra.57

1.35% [kernel] [k] read_tsc

1.24% [kernel] [k] ip_rcv

 

А нельзя добавить в старую версию LEAF 4.2.1 bird и birdc которые IPv4 ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Может только по IP. Я не смотрел, если честно. Проверьте.

 

добавив + 20кPPS выскакивает softirq 100%

Это с RPS? Или со скачущими прерываниями? Если второе - то не удивительно, т.к. пиковая загрузка ядра у вас более 50%. Почему - писал выше.

 

А нельзя добавить в старую версию LEAF 4.2.1 bird и birdc которые IPv4 ?

В 4.3 бета2 будут. Можете с гита срез собрать.

К слову, попробуйте этот срез погонять на тестах. Я в нем планировщик заданий сменил на bfs, вроде как более шустрый и менее прожорливый, хоть и масштабируется на системах с несколькими десятками ядер/голов хуже (что, думаю, в данном случае не критично) - интересно как это скажется на производительности ядра...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это с RPS? Или со скачущими прерываниями? Если второе - то не удивительно, т.к. пиковая загрузка ядра у вас более 50%. Почему - писал выше.

Это со "скачущими прерываниями". 4.2.1 показал со "скачущими прерываниями" результат лучше чем LEAF который Вы предложили потестить в посте от 17 июня 2012 - 19:57 http://ifolder.ru/31154168 на 13%.

 

RPS еще не вразумил как настроить на системе с 8 ядрами и 16 очередями сетевого интерфейса.

testrouter# ls /sys/class/net/eth2/queues/

rx-0 rx-1 rx-10 rx-11 rx-12 rx-13 rx-14 rx-15 rx-2 rx-3 rx-4 rx-5 rx-6 rx-7 rx-8 rx-9 tx-0 tx-1 tx-2 tx-3 tx-4 tx-5 tx-6 tx-7

testrouter#

Изменено пользователем QWE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

4.2.1 показал со "скачущими прерываниями" результат лучше чем LEAF который Вы предложили потестить в посте от 17 июня 2012 - 19:57 http://ifolder.ru/31154168 на 13%.

Может быть, я 3.2 ядро под нагрузкой особо не тестил. Сравните со срезом из прошлого поста, будет ли разница.

 

RPS еще не вразумил как настроить на системе с 8 ядрами и 16 очередями сетевого интерфейса.

Да всем очередям маску ffff присваиваете и все...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

к NiTrO:

 

и ещё можно маленький вопрос:при использовании других сборок таких как IPCOP,IPFIRE, DEVIL-LINUX есть возможность использовать звук при загрузке,подключение и отключении к инету;в лифе есть такая возможность и если есть,то как это реализовать....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Драйверы звуковых карт есть, в первую очередь для asterisk'а, всяческих пикалок - нет (потому как никому из разработчиков не нужны). Можете портировать какой-то консольный плеер (в 4.x ветке к слову есть mpg123, в 5.x - пока выпилен за ненадобностью, если кому-то сильно понадобится - можно будет и вернуть), и несколькими скриптами заставить его делать то, что вам нужно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Может быть, я 3.2 ядро под нагрузкой особо не тестил. Сравните со срезом из прошлого поста, будет ли разница.

 

Да всем очередям маску ffff присваиваете и все...

 

 

Установил

 

firewall# uname -a

Linux firewall 3.2.19-i686 #1 SMP Tue Jun 19 00:47:26 EEST 2012 i686 GNU/Linux

firewall#

 

 

Разница особая не обнаружена, может быть чуть чуть лучше. Но скорее это мое субъективное мнение.

 

 

 

 

firewall# echo ffff > /sys/class/net/eth2/queues/rx-0/rps_cpus

sh: write error: Value too large for defined data type

 

firewall# echo ff > /sys/class/net/eth2/queues/rx-0/rps_cpus

 

Прошло вот так

 

echo ff > /sys/class/net/eth2/queues/rx-0/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-1/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-2/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-3/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-4/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-5/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-6/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-7/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-8/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-9/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-10/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-11/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-12/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-13/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-14/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-15/rps_cpus

 

но softirqd стал вылезать на 100% при том количестве пакетов при котором "скачущие прерывания" работали еще уверенно 560к PPS

Вывод. С RPS хуже или я неправильно сконфигурил его.

Изменено пользователем QWE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У вас работает на стенде только eth2? Или 2 интерфейса сетевухи все же?

И прибейте очереди к ядрам в /proc/irq/<прерывание очереди>/smp_affinity.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У вас работает на стенде только eth2? Или 2 интерфейса сетевухи все же?

И прибейте очереди к ядрам в /proc/irq/<прерывание очереди>/smp_affinity.

echo ff > /sys/class/net/eth2/queues/rx-0/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-1/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-2/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-3/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-4/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-5/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-6/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-7/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-8/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-9/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-10/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-11/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-12/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-13/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-14/rps_cpus

echo ff > /sys/class/net/eth2/queues/rx-15/rps_cpus

 

echo ff > /sys/class/net/eth3/queues/rx-0/rps_cpus

echo ff > /sys/class/net/eth3/queues/rx-1/rps_cpus

echo ff > /sys/class/net/eth3/queues/rx-2/rps_cpus

echo ff > /sys/class/net/eth3/queues/rx-3/rps_cpus

echo ff > /sys/class/net/eth3/queues/rx-4/rps_cpus

echo ff > /sys/class/net/eth3/queues/rx-5/rps_cpus

echo ff > /sys/class/net/eth3/queues/rx-6/rps_cpus

echo ff > /sys/class/net/eth3/queues/rx-7/rps_cpus

echo ff > /sys/class/net/eth3/queues/rx-8/rps_cpus

echo ff > /sys/class/net/eth3/queues/rx-9/rps_cpus

echo ff > /sys/class/net/eth3/queues/rx-10/rps_cpus

echo ff > /sys/class/net/eth3/queues/rx-11/rps_cpus

echo ff > /sys/class/net/eth3/queues/rx-12/rps_cpus

echo ff > /sys/class/net/eth3/queues/rx-13/rps_cpus

echo ff > /sys/class/net/eth3/queues/rx-14/rps_cpus

echo ff > /sys/class/net/eth3/queues/rx-15/rps_cpus

 

+ прибил eth3-TxRx-7 к CPU0

 

echo "01" > /proc/irq/84/smp_affinity

 

+ прибил eth2-TxRx-6 к CPU1

 

echo "02" > /proc/irq/72/smp_affinity

 

600кPPS видел, потерь на интерфейсе по приему не было.

top

CPU0: 0.0% usr 0.0% sys 0.0% nic 99.3% idle 0.0% io 0.0% irq 0.6% sirq

CPU1: 0.0% usr 0.0% sys 0.0% nic 98.9% idle 0.0% io 0.0% irq 1.0% sirq

CPU2: 0.0% usr 0.0% sys 0.0% nic 100% idle 0.0% io 0.0% irq 0.0% sirq

CPU3: 0.0% usr 0.0% sys 0.0% nic 100% idle 0.0% io 0.0% irq 0.0% sirq

CPU4: 8.2% usr 0.0% sys 0.0% nic 0.0% idle 0.0% io 0.0% irq 91.7% sirq

CPU5: 0.0% usr 0.0% sys 0.0% nic 100% idle 0.0% io 0.0% irq 0.0% sirq

CPU6: 0.0% usr 0.0% sys 0.0% nic 100% idle 0.0% io 0.0% irq 0.0% sirq

CPU7: 0.0% usr 0.0% sys 0.0% nic 100% idle 0.0% io 0.0% irq 0.0% sirq

 

По ощущениям - стабильнее, но вопросы все равно есть.

1. Получается работают только два проца (тест искусственный 1 src ip 1 dst ip)

2. Почему вылез ksoftirqd на CPU4?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас