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

Intel 82599 и LRO + ряд вопросов по softirq

ЧАСТЬ 1:

Имеется Intel 82599EB и два способа отключения LRO.

1. modprobe ixgbe LRO=0

2. ethtool -K eth0 lro off

Какой способ правильный и идет ли речь об одном и том же параметре LRO или это все же разные опции?

---------

ЧАСТЬ 2:

При использовании сервера в качестве L3 routing машины надо ли отключать опции ethtool -K gro, gso, tso, lro или пофиг (раньше отключал)?

---------

ЧАСТЬ 3:

При переходе с двух 4-х портовых 82576 на одну 82599 резко возросла нагрузка на CPU вплоть до 100% загрузки на ровном месте.

Ничего не менялось, кроме вытаскивания одной железки и втыкания другой в ту же самую машину, ну и соответственно сборки другого драйвера.

Собрал 3.19.1, хотя ядерный был 3.6.7.

С чего бы вдруг случилось такое поведение машины? Может 3.19.1 глючной попался? Никто не сталкивался с подобным?

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


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

Имхо, пофиг, но вот что обязательно нужно выключить, так это:

ethtool -K ethX tso off

У нас на 3.2 ядре оно пакеты било ужасающе. Все остальное не так влияет (по крайне мере мы не заметили).

 

Для ixgbe стандартно отключено распределение по всем 8 ми очередям для обработки трафика, включите в ixgbe.conf это, сделать можно примерно так:

options ixgbe InterruptType=2,2,2,2,2,2 MQ=1,1,1,1,1,1 DCA=2,2,2,2,2,2 RSS=0,0,0,0,0,0 VMDQ=0,0,0,0,0,0 max_vfs=0,0,0,0,0,0 L2LBen=0,0,0,0,0,0 
InterruptThrottleRate=1,1,1,1,1,1 FCoE=0,0,0,0,0,0 LRO=0,0,0,0,0,0 allow_unsupported_sfp=0,0,0,0,0,0

Изменено пользователем pavel.odintsov

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


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

У меня 4 ядра Xeon E3 1240v2 -3.4 GHz без HT, поэтому мне не надо 8 очередей. У меня по две комбинированные очереди на порт 10Г.

 

Соответственно загружаю драйвер с опциями /sbin/modprobe ixgbe IntMode=2,2 RSS=2,2 DCA=2,2 LRO=0,0

 

Далее просто прибиваю очереди к ядрами типа так

 

echo 1 > /proc/irq/42/smp_affinity

echo 2 > /proc/irq/43/smp_affinity

echo 4 > /proc/irq/45/smp_affinity

echo 8 > /proc/irq/46/smp_affinity

 

Что значит отсутствует распределение по очередям?

 

В cat /proc/interrupts четко видны очереди по две на каждый порт 10Г прибитые к ядрам.

 

42:   35332028          2          2          1   PCI-MSI-edge      eth0-TxRx-0
43:          3   30171958          0          3   PCI-MSI-edge      eth0-TxRx-1

45:          2          0   39410653          2   PCI-MSI-edge      eth1-TxRx-0
46:          1          3          0   37290726   PCI-MSI-edge      eth1-TxRx-1

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

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


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

А perf top что показывает?

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


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

А perf top что показывает?

 

Когда поставили ixgbe, то стало так

 

PerfTop: 23194 irqs/sec kernel:99.8% [100000 cycles], (all, 4 CPUs)

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

 

samples pcnt kernel function

_______ _____ _______________

 

133504.00 - 38.4% : gre_pkt_to_tuple

130579.00 - 37.5% : memcmp

11445.00 - 3.3% : intel_idle

7069.00 - 2.0% : ixgbe_poll [ixgbe]

7041.00 - 2.0% : ipt_do_table

2335.00 - 0.7% : nf_iterate

2334.00 - 0.7% : _raw_spin_lock

2330.00 - 0.7% : ip_route_input_common

2170.00 - 0.6% : __slab_free

2157.00 - 0.6% : ixgbe_xmit_frame_ring [ixgbe]

1687.00 - 0.5% : ____nf_conntrack_find

1637.00 - 0.5% : dev_queue_xmit

1605.00 - 0.5% : irq_entries_start

1450.00 - 0.4% : eth_type_trans

1050.00 - 0.3% : vlan_do_receive

 

================= пока стояли igb картинка была такой, т.е. никакого to_tuple не было в помине ...

 

PerfTop: 8142 irqs/sec kernel:99.2% [100000 cycles], (all, 4 CPUs)

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

 

samples pcnt kernel function

_______ _____ _______________

 

12096.00 - 10.1% : igb_poll [igb]

10523.00 - 8.8% : intel_idle

6675.00 - 5.6% : ipt_do_table

5089.00 - 4.2% : __memcpy

4265.00 - 3.6% : _raw_spin_lock

4022.00 - 3.3% : irq_entries_start

2741.00 - 2.3% : __slab_free

2190.00 - 1.8% : nf_iterate

1939.00 - 1.6% : dev_queue_xmit

1784.00 - 1.5% : __napi_complete

1773.00 - 1.5% : igb_xmit_frame_ring [igb]

1653.00 - 1.4% : rcu_enter_nohz

1629.00 - 1.4% : ____nf_conntrack_find

1567.00 - 1.3% : __slab_alloc.constprop.69

1546.00 - 1.3% : ksize

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

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


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

Такое чувство, что сервак что-то пытается сделать с пролетающими через него pptp туннелями, но зачем?

Откуда ноги у gre_pkt_to_tuple ?

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

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


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

Все разобрался. Слона-то и не заметил.

Причиной был подгрузившийся модуль NF_CONNTRACK_PPTP.

После выгрузки все нормализовалось.

 

Нагрузка на CPU железяки при пролетающих через нее суммарно 1.5 Гбит/с трафика теперь около 2.5-3.5%.

Так и должно быть. Соответственно все остальные риторические вопросы тоже отпали сами собой.

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

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


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

intel_idle тоже надо убить, смотрите соседнюю ветку.

 

Раскладка по прерываниям, когда у каждого интерфейса есть вектор на каждом ядре может оказаться эффективней, т.е. по 4 на интерфейс и оба "лесенкой".

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


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

Раскладка по прерываниям, когда у каждого интерфейса есть вектор на каждом ядре может оказаться эффективней, т.е. по 4 на интерфейс и оба "лесенкой".

С этим согласен, но пока искал причину, то пришлось уменьшить до RSS=2,2, вместо 4,4.

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


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

intel_idle тоже надо убить, смотрите соседнюю ветку.

Т.е. я правильно понял что надо выкосить из ядра вот это

CONFIG_CPU_IDLE=y

CONFIG_CPU_IDLE_GOV_LADDER=y

CONFIG_CPU_IDLE_GOV_MENU=y

CONFIG_INTEL_IDLE=y

 

А также в lilo (у меня он загрузчиком стоит) прописать эти две строки?

intel_idle.max_cstate=0

processor.max_cstate=1

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

 

В принципе powertop показывает что частота гуляет в пределах от 2.8 до 3.4 ГГц, поэтому не критично, хотя и неприятно с этим idle получается.

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

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


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

Достаточно убрать CONFIG_INTEL_IDLE или выставить параметр ядра.

 

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

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


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

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

Cstate 1 это не изменение частоты, а банальный halt в бездействии. Который практически бесплатен и дает огромную экономию энергии в сравнении с постоянным лупом(вспоминайте времена win95, когда этого халта не было в системе и охлаждали CPU программы типа waterfall).

 

IMHO все-таки параметры intel_idle.max_cstate=0 processor.max_cstate=1(отключение intel idle, максимальный уровень сбережения - halt) оптимальны. Не зря их intel/hp/etc рекомендуют в сетевых гайдах.

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

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


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

Cstate 1 это не изменение частоты, а банальный halt в бездействии

Изменение частоты касалось фразы "частота гуляет в пределах от 2.8 до 3.4 ГГц" топикстартера. И C1 тоже не глубокий сон, о котором писал :)

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


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

vitalyb

Согласен. Просто в последнее время вижу все больше рекомендаций косить все энергосбережение полностью, это не есть хорошо.

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


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

Указание параметров ядра решает и вопросы с частотой.

 

powertop говорит

         Package   |             Core    |            CPU 0
                   |                     | C0 active   inf%
C2 (pc2)    0.0%    |                     |
C3 (pc3)    0.0%    | C3 (cc3)    0.0%    |
C6 (pc6)    0.0%    | C6 (cc6)    0.0%    |
C7 (pc7)    0.0%    | C7 (cc7)    0.0%    |

                   |             Core    |            CPU 1
                   |                     | C0 active   inf%
                   |                     |
                   | C3 (cc3)    0.0%    |
                   | C6 (cc6)    0.0%    |
                   | C7 (cc7)    0.0%    |

                   |             Core    |            CPU 2
                   |                     | C0 active   inf%
                   |                     |
                   | C3 (cc3)    0.0%    |
                   | C6 (cc6)    0.0%    |
                   | C7 (cc7)    0.0%    |

                   |             Core    |            CPU 3
                   |                     | C0 active   inf%
                   |                     |
                   | C3 (cc3)    0.0%    |
                   | C6 (cc6)    0.0%    |
                   | C7 (cc7)    0.0%    |

 

Т.е. состояния С2,C3,C6,C7 не используются. А дальше показывает, что

            Package |             Core    |            CPU 0
                   |                     | Actual            0
Idle       100.0%   | Idle       100.0%   | Idle       100.0%

                   |             Core    |            CPU 1
                   |                     | Actual            0
                   | Idle       100.0%   | Idle       100.0%

                   |             Core    |            CPU 2
                   |                     | Actual            0
                   | Idle       100.0%   | Idle       100.0%

                   |             Core    |            CPU 3
                   |                     | Actual            0
                   | Idle       100.0%   | Idle       100.0%

 

частота 100% и больше нет смысла выводить показатель Actual в GHz.

 

В perf top появился irq_entries_start, которого раньше не было. Ну и при RSS=4,4 нагрузка на si стала чуть больше.

samples    pcnt   kernel function
            _______   _____   _______________

            7203.00 - 11.9% : irq_entries_start
            6276.00 - 10.4% : ixgbe_poll       [ixgbe]
            4758.00 -  7.9% : ipt_do_table
            2332.00 -  3.9% : add_interrupt_randomness
            2040.00 -  3.4% : _raw_spin_lock
            1530.00 -  2.5% : nf_iterate
            1385.00 -  2.3% : ixgbe_xmit_frame_ring    [ixgbe]
            1054.00 -  1.7% : dev_queue_xmit
            1025.00 -  1.7% : ip_route_input_common
             922.00 -  1.5% : rcu_enter_nohz
             879.00 -  1.5% : ____nf_conntrack_find
             862.00 -  1.4% : eth_type_trans
             851.00 -  1.4% : local_bh_enable
             766.00 -  1.3% : __napi_complete
             666.00 -  1.1% : tick_nohz_stop_sched_tick

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


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

У меня дебиан ядро 3.16 в sysctl не одно параметра связанного с idle или cstate нет.

Ядро собрано без этого.

Но при задействовании двух 6ти ядерных камней Intel® Xeon® CPU X5670 при низкой нагрузке появляются дропы, всё перепробовал не могу решить проблему.

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


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

У меня было такое . Когда в одном vlan был loop (раз 1 час включался порт клиента и вырублася ), то на карты 82599 взлетел CPU до 100%. Серверы с 82576 такого не почувствовали. Может у вас чистый L3 и vlan не дохядт пачками.

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


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

Хоть бы кто-то написал что не один из этих параметров не видно в sysctl и, что нужно полюбому передавать через GRUB_CMDLINE_LINUX_DEFAULT="quiet processor.max_cstate=1 intel_idle.max_cstate=0"

Посмотрим даст оно что-то или нет.

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


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

Отпишитесь плиз по результатам

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


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

Сервер:

Материнка: Tean

Проц: Intel® Xeon® CPU X5670 *2

Сетевые :

двухголовая Selimicon Intel 82599 (1 порт SFP+ входящий канал второго прова, 2 порт смотрит в локалку) eth0 eth1

двухголовая Intel 82576 в LACP (входящий канал одного провайдера) eth2 eth3

 

Нагрузка:

6c47835bb3.jpg

3544248038.jpg

eth0      Link encap:Ethernet  HWaddr 00:e0:ed:2d:24:df  
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:5376385179 errors:0 dropped:0 overruns:0 frame:0
         TX packets:3828422980 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:10000 
         RX bytes:6252906728086 (5.6 TiB)  TX bytes:1534230664189 (1.3 TiB)

eth1      Link encap:Ethernet  HWaddr 00:e0:ed:2d:24:de  
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:4972876866 errors:0 dropped:1 overruns:0 frame:0
         TX packets:7218214228 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:10000 
         RX bytes:2075368983221 (1.8 TiB)  TX bytes:8545645631048 (7.7 TiB)
eth2      Link encap:Ethernet  HWaddr 00:1b:21:a1:05:92  
         UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
         RX packets:923259881 errors:0 dropped:0 overruns:0 frame:0
         TX packets:493192217 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000 
         RX bytes:1063932576905 (990.8 GiB)  TX bytes:171104097462 (159.3 GiB)
eth3      Link encap:Ethernet  HWaddr 00:1b:21:a1:05:92  
         UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
         RX packets:922905096 errors:0 dropped:17 overruns:0 frame:0
         TX packets:558827639 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000 
         RX bytes:1060293498441 (987.4 GiB)  TX bytes:251065695390 (233.8 GiB)

 

# uptime 
17:11:00 up 14:41,  2 users,  load average: 0,14, 0,24, 0,30

 

Пока полёт отличный

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

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


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

Сервер:

Материнка: Tean

Проц: Intel® Xeon® CPU X5670 *2

Сетевые :

двухголовая Selimicon Intel 82599 (1 порт SFP+ входящий канал второго прова, 2 порт смотрит в локалку) eth0 eth1

двухголовая Intel 82576 в LACP (входящий канал одного провайдера) eth2 eth3

 

Нагрузка:

 

# uptime 
17:11:00 up 14:41,  2 users,  load average: 0,14, 0,24, 0,30

 

Пока полёт отличный

А какие задачи на таких процессорах крутятся? только роутинг + bgp? fv ? ipt_NETFLOW модуль есть?

Сколько pps прожует Ваша конфигурация для задач роутинг + bgp + fv + ipt_NETFLOW ?

Какое ядро? дистр?

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

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


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

Сервер:

Материнка: Tean

Проц: Intel® Xeon® CPU X5670 *2

Сетевые :

двухголовая Selimicon Intel 82599 (1 порт SFP+ входящий канал второго прова, 2 порт смотрит в локалку) eth0 eth1

двухголовая Intel 82576 в LACP (входящий канал одного провайдера) eth2 eth3

 

Нагрузка:

 

# uptime 
17:11:00 up 14:41,  2 users,  load average: 0,14, 0,24, 0,30

 

Пока полёт отличный

А какие задачи на таких процессорах крутятся? только роутинг + bgp? fv ? ipt_NETFLOW модуль есть?

Сколько pps прожует Ваша конфигурация для задач роутинг + bgp + fv + ipt_NETFLOW ?

Какое ядро? дистр?

 

 

Это пограничник + NAS , куча правил iptables с ipset,

так же CONNTRACK выключен при помощи raw NOTRACK,

включен только для определённых ipset для редиректа абонентов на страницы заглушки,

ещё на нём multicast в unicast перегоняется при помощи astra до 500M.

При нормальной работе наверное около 1M PPS в чнн при атаках и около трёх проскакивало.

Debian 6, Ядро 3.16.

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


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

Debian 6, Ядро 3.16.

 

Вам не страшно такое древнее на границе держать?

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


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

Сервер:

Материнка: Tean

Проц: Intel® Xeon® CPU X5670 *2

Сетевые :

двухголовая Selimicon Intel 82599 (1 порт SFP+ входящий канал второго прова, 2 порт смотрит в локалку) eth0 eth1

двухголовая Intel 82576 в LACP (входящий канал одного провайдера) eth2 eth3

 

Нагрузка:

 

# uptime 
17:11:00 up 14:41,  2 users,  load average: 0,14, 0,24, 0,30

 

Пока полёт отличный

А какие задачи на таких процессорах крутятся? только роутинг + bgp? fv ? ipt_NETFLOW модуль есть?

Сколько pps прожует Ваша конфигурация для задач роутинг + bgp + fv + ipt_NETFLOW ?

Какое ядро? дистр?

 

 

Это пограничник + NAS , куча правил iptables с ipset,

так же CONNTRACK выключен при помощи raw NOTRACK,

включен только для определённых ipset для редиректа абонентов на страницы заглушки,

ещё на нём multicast в unicast перегоняется при помощи astra до 500M.

При нормальной работе наверное около 1M PPS в чнн при атаках и около трёх проскакивало.

Debian 6, Ядро 3.16.

прерывания как разбросаны, если не секрет?

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


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.