QWE Опубликовано 17 июня, 2012 · Жалоба заглянул в пакет 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 ...). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 17 июня, 2012 · Жалоба Ок, понял, поправлю... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 17 июня, 2012 · Жалоба Поправил bird, собрал тестовый срез 5.0 ветки с исправлениями, желающие проверить - могут стянуть отсюда. Проблем наблюдаться не должно, а вот утечки памяти ядра (предположительно - где-то в сетевой подсистеме при создании/удалении маршрутов) - таки исчезли (то ли в связи с апдейтом ядра, то ли с включением дебага - т.к. в 3.2.6 или 3.2.12-13 еще были, после обновления до 3.2.19 и включения kmemleak внезапно испарились) 5.0 альфа (а может - сразу и бета) ожидается где-то в этом или следующем месяце, как руки дойдут реализовать пару полезных фич. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 18 июня, 2012 · Жалоба 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 Почему не грузится ? Какой версии модуль? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 18 июня, 2012 (изменено) · Жалоба Поправил bird, собрал тестовый срез 5.0 ветки с исправлениями, желающие проверить - могут стянуть отсюда. Проблем наблюдаться не должно, а вот утечки памяти ядра (предположительно - где-то в сетевой подсистеме при создании/удалении маршрутов) - таки исчезли (то ли в связи с апдейтом ядра, то ли с включением дебага - т.к. в 3.2.6 или 3.2.12-13 еще были, после обновления до 3.2.19 и включения kmemleak внезапно испарились) 5.0 альфа (а может - сразу и бета) ожидается где-то в этом или следующем месяце, как руки дойдут реализовать пару полезных фич. Загрузился. Хотел проверить в новой сборке igb модуль но рутом с пустым паролем не пускает, - возможно из за того что поверх старой версии распаковал новую Изменено 18 июня, 2012 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 18 июня, 2012 · Жалоба охранил конфиг, перезапустил сервер. но в логах dmesg DROPы shorewall конфигурить надо, и он конфигурится никак не в inetd и не в hosts.allow. Не хотите с ним возиться - отключите, юзайте голый иптейблс. однако при загрузке LEAF в частности модуля igb ошибки в dmesg Модуль dca имеется? Вообще для разрешения подобных проблем и предусмотрена автоматическая подгрузка нужных модулей в меню... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 18 июня, 2012 (изменено) · Жалоба перенес все тесты из 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 сохранился, затем ребутнулся. Пакетов нет(( Изменено 18 июня, 2012 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 18 июня, 2012 · Жалоба Суммарно по top загрузки нет никакой, как то сомнительно. %hi %si %sy смотрите, должно немного присутствовать. Это с нетфлоу или без? А по поводу очередей - странно конечно. Как вариант - заюзать RPS/RFS (хотя от второго толку не сильно много) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 18 июня, 2012 · Жалоба Суммарно по 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, но прерывания генерит только одна очередь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 18 июня, 2012 · Жалоба делаю вывод ipt_NETFLOW добавляет к загрузке более чем 15% Возможно, упирается в процессорную шину все, раз так резко загрузка подскакивает. Все-таки обе головы висят на одной шине и делят ее между своими ядрами... Если это так - то распараллеливание ничего особо не даст. А что значит заюзать RPS? http://forum.nag.ru/forum/index.php?showtopic=59217 Вполне неплохая вещь... гружу igb RSS=0,0 А чего не 8,8? 0,0 - вроде как отключение очередей же. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 19 июня, 2012 · Жалоба А чего не 8,8? 0,0 - вроде как отключение очередей же. Одинаково создаются и в том и друом случае по 8TxRx на каждый интерфейс. 0,0 это типа драйвер сам решает сколько делать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 19 июня, 2012 (изменено) · Жалоба 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. Изменено 19 июня, 2012 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 19 июня, 2012 · Жалоба 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 ядро), и посмотрите на результат. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 19 июня, 2012 · Жалоба В общем, на каждой очереди включите 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 чтобы это произошло? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 19 июня, 2012 · Жалоба как бы ни грузился драйвер (неважно какие очереди сдвоенные одинарные) - всегда загружена только одна очередь, которая соответственно висит на одном прерывании Проблема драйвера/железа/чего там еще, на это скорее сего только разработчики повлияют... но при этом равномерно загружены все процессоры от этого IRQ В среднем - равномерно. В конкретный момент времени - только одно ядро работает, остальные гуляют. Я может непонимаю конечно как сделать вот это "В общем, на каждой очереди включите RPS на все ядра"... echo ffff > /sys/class/net/eth0/queues/rx-0/rps_cpus и т.д. для каждой очереди. По моей логике - как только есть несколько очередей на прием, то драйвер автоматом входящие пакеты распределяет равномерно в число организованных очередей, которые в свою очередь висят на разных прерываниях и те в свою очередь "прибиваются" к ядрам. Распараллеливает пакеты даже не драйвер, а чип исходя из хеша src:dst IP/port (если не ошибаюсь). От того распараллеливания нет на PPPoE в частности. А вот почему нормального распараллеливания нет на обычном траффике - вопрос... Тогда вопрос простой с каким параметрами грузить igb чтобы это произошло? Что произошло? Прибивание к ядрам - так это из юзерленда рулится через smp_affinity. Распараллеливание - вроде драйвер/чип должен равномерно распараллеливать, почему не хочет - неведомо (можно попытаться тикет создать, может пофиксят когда-то). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 19 июня, 2012 (изменено) · Жалоба 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 всегда одинаковы. И пакеты будут раскладываться на реальном трафике... Изменено 19 июня, 2012 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 20 июня, 2012 · Жалоба настроил роутер на тестовой версии 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 ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 20 июня, 2012 · Жалоба Может быть порты не учавствуют при распределении трафика по очередям? Может только по IP. Я не смотрел, если честно. Проверьте. добавив + 20кPPS выскакивает softirq 100% Это с RPS? Или со скачущими прерываниями? Если второе - то не удивительно, т.к. пиковая загрузка ядра у вас более 50%. Почему - писал выше. А нельзя добавить в старую версию LEAF 4.2.1 bird и birdc которые IPv4 ? В 4.3 бета2 будут. Можете с гита срез собрать. К слову, попробуйте этот срез погонять на тестах. Я в нем планировщик заданий сменил на bfs, вроде как более шустрый и менее прожорливый, хоть и масштабируется на системах с несколькими десятками ядер/голов хуже (что, думаю, в данном случае не критично) - интересно как это скажется на производительности ядра... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 20 июня, 2012 (изменено) · Жалоба Это с 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# Изменено 20 июня, 2012 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 20 июня, 2012 · Жалоба 4.2.1 показал со "скачущими прерываниями" результат лучше чем LEAF который Вы предложили потестить в посте от 17 июня 2012 - 19:57 http://ifolder.ru/31154168 на 13%. Может быть, я 3.2 ядро под нагрузкой особо не тестил. Сравните со срезом из прошлого поста, будет ли разница. RPS еще не вразумил как настроить на системе с 8 ядрами и 16 очередями сетевого интерфейса. Да всем очередям маску ffff присваиваете и все... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
termez12 Опубликовано 21 июня, 2012 · Жалоба к NiTrO: и ещё можно маленький вопрос:при использовании других сборок таких как IPCOP,IPFIRE, DEVIL-LINUX есть возможность использовать звук при загрузке,подключение и отключении к инету;в лифе есть такая возможность и если есть,то как это реализовать.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 21 июня, 2012 · Жалоба Драйверы звуковых карт есть, в первую очередь для asterisk'а, всяческих пикалок - нет (потому как никому из разработчиков не нужны). Можете портировать какой-то консольный плеер (в 4.x ветке к слову есть mpg123, в 5.x - пока выпилен за ненадобностью, если кому-то сильно понадобится - можно будет и вернуть), и несколькими скриптами заставить его делать то, что вам нужно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 21 июня, 2012 (изменено) · Жалоба Может быть, я 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 хуже или я неправильно сконфигурил его. Изменено 21 июня, 2012 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 21 июня, 2012 · Жалоба У вас работает на стенде только eth2? Или 2 интерфейса сетевухи все же? И прибейте очереди к ядрам в /proc/irq/<прерывание очереди>/smp_affinity. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 25 июня, 2012 · Жалоба У вас работает на стенде только 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? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...