Привязка прерываний к ядру для сетевых карт

Всем доброго времени суток.

Возникла задача - привязать прерывания пяти сетевых карт (из которых 4 объединены в bond) к ядрам процессора.

Попробовал через postup() - но он вызывается при поднятии 5-й сетевой, и bond0, а на поднятие сетевух из bond0 postup() не реагирует. Пришлось сделать вот так:

postup() {
    [ "${IFACE}" = "bond0" ] && /root/bin/irq-affinity.sh net1 net2 net3 net4
    [ "${IFACE}" = "net5" ] && /root/bin/irq-affinity.sh net5
}

Вроде, и аккуратно смотрится - но все равно как-то не изящно (тем более, "левый" скрипт вызывается).

Может, есть более простое решение?

/bin/echo 1 >

    /bin/echo 1 >    /proc/irq/`cat /proc/interrupts | grep 'int1-TxRx-0' | awk -F \: '{printf "%i", $1}'`/smp_affinity
    /bin/echo 2 >    /proc/irq/`cat /proc/interrupts | grep 'int0' | awk -F \: '{printf "%i", $1}'`/smp_affinity

например аналогичное этому поместить в postup и все.

Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!

_passer написал(а):

_passer написал(а):
    /bin/echo 1 >    /proc/irq/`cat /proc/interrupts | grep 'int1-TxRx-0' | awk -F \: '{printf "%i", $1}'`/smp_affinity
    /bin/echo 2 >    /proc/irq/`cat /proc/interrupts | grep 'int0' | awk -F \: '{printf "%i", $1}'`/smp_affinity

например аналогичное этому поместить в postup и все.

Я немного не про это. Если Вы обратили внимание - я как раз и использую postup().

Работа скрипта, кторый я использую (irq-affinity.sh) меня как раз устраивает (он универсальный, поддерживает до 64 очередей, "понимает" два варианта распределения очередей - когда TxRx вместе, или когда tx и rx отдельно).

Меня интересовало, есть ли в Gentoo какие-то "стандартные" средства для "прибивания" прерываний (наподобие ethtool_ring_XXX или ethtool_pause_XXX).

нету А что, где то есть ?

нету
А что, где то есть ?

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

Если не секрет

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

Для обработки большого

Для обработки большого количества траффика с малыми задрежками - при переходе обработки прерывания на другое ядро по irqbalance "срывает" очеред конвеера блока исполнения и нужно начинать с последней точки сохранения состояния.
Аналогичная техника используется для "прибивания" qemu или iptables к процам.
Вообще идея прибивания используется при обработке потока мелких транзакций на SMP/NUMA машине .
Фича чисто для нормального прода и дома никак никогда совершенно не нужна ;)
http://www.intel.com/content/www/us/en/ethernet-controllers/82575-82576-82598-82599-ethernet-controllers-interrupts-appl-note.html

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

Спасибо

Спасибо, за обстоятельный ответ.

Неравномерное распределение прерываний от сетевой карты

У вышеописанной задачи появилось продолжение.

Система почти 3 месяца очень красиво работала - графики загрузки всех процессоров были довольно близки друг к другу. Убедившись, что все работает, заглядывать в графики перестали.

Сейчас же наблюдается очень нехорошая картинка: загрузка первого процессора в 3-4 раза превышает загрузку остальных, а когда первый упирается в 100% - загрузка остальных падает еще сильнее.

Вот текущее содержимое файла /proc/interrupts

           CPU0       CPU1       CPU2       CPU3
  0:         12          0          0          0   IO-APIC-edge      timer
  1:         68         24          3          0   IO-APIC-edge      i8042
  8:         53          0          0          1   IO-APIC-edge      rtc0
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 20:         26          5          1          1   IO-APIC-fasteoi   ehci_hcd:usb1
 23:         36          0          1          0   IO-APIC-fasteoi   ehci_hcd:usb2
 44:     447273     307385      65505      16132   PCI-MSI-edge      ahci
 45:          0          0          0          0   PCI-MSI-edge      ahci
 46:       5723       1097        403        745   PCI-MSI-edge      xhci_hcd
 47:   87514402  110618786   27390742    7524704   PCI-MSI-edge      net0
 48:          2          0          0          0   PCI-MSI-edge      net1
 49:   68248125          0          3          1   PCI-MSI-edge      net1-rx-0
 50:          5     409441          2          1   PCI-MSI-edge      net1-rx-1
 51:          5          0     409443          1   PCI-MSI-edge      net1-rx-2
 52:          5          0          2     409442   PCI-MSI-edge      net1-rx-3
 53:     409446          0          2          1   PCI-MSI-edge      net1-tx-0
 54:          5     409441          2          1   PCI-MSI-edge      net1-tx-1
 55:          5          0     409443          1   PCI-MSI-edge      net1-tx-2
 56:         10          0          2  316790125   PCI-MSI-edge      net1-tx-3
 57: 3032267907        783        111         24   PCI-MSI-edge      net5-TxRx-0
 58:         21 2628025916         21          3   PCI-MSI-edge      net5-TxRx-1
 59:         14         28 2634206541          2   PCI-MSI-edge      net5-TxRx-2
 60:         29         10          0 2809140920   PCI-MSI-edge      net5-TxRx-3
 61:      63166     163200      41478      11329   PCI-MSI-edge      net5
 62:          2          0          0          0   PCI-MSI-edge      net2
 63:   70898076          0          2          1   PCI-MSI-edge      net2-rx-0
 64:          5     409440          1          1   PCI-MSI-edge      net2-rx-1
 65:          5          0     409441          1   PCI-MSI-edge      net2-rx-2
 66:          5          0          1     409441   PCI-MSI-edge      net2-rx-3
 67:     409445          0          1          1   PCI-MSI-edge      net2-tx-0
 68:          5     409440          1          1   PCI-MSI-edge      net2-tx-1
 69:          5          0     409441          1   PCI-MSI-edge      net2-tx-2
 70:          8          0          1  160969092   PCI-MSI-edge      net2-tx-3
 71:          2          0          0          0   PCI-MSI-edge      net3
 72:   73691263          1          1          1   PCI-MSI-edge      net3-rx-0
 73:          5     409437          1          1   PCI-MSI-edge      net3-rx-1
 74:          5          0     409438          1   PCI-MSI-edge      net3-rx-2
 75:          5          0          1     409438   PCI-MSI-edge      net3-rx-3
 76:     409442          0          1          1   PCI-MSI-edge      net3-tx-0
 77:          5     409437          1          1   PCI-MSI-edge      net3-tx-1
 78:          5          0     409438          1   PCI-MSI-edge      net3-tx-2
 79:          8          0          1     567120   PCI-MSI-edge      net3-tx-3
 80:          2          0          0          0   PCI-MSI-edge      net4
 81:   83930198          0          2          0   PCI-MSI-edge      net4-rx-0
 82:          6     409438          2          0   PCI-MSI-edge      net4-rx-1
 83:          6          0     409440          0   PCI-MSI-edge      net4-rx-2
 84:          6          0          2     409438   PCI-MSI-edge      net4-rx-3
 85:     409444          0          2          0   PCI-MSI-edge      net4-tx-0
 86:          5     409438          2          1   PCI-MSI-edge      net4-tx-1
 87:          5          0     409441          0   PCI-MSI-edge      net4-tx-2
 88:          8          1          2    2096541   PCI-MSI-edge      net4-tx-3
NMI:          0          0          0          0   Non-maskable interrupts
LOC:   80847953   71207768   70438568   70498871   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:          0          0          0          0   Performance monitoring interrupts
IWI:    1932047    1167224     654810     552401   IRQ work interrupts
RTR:          3          0          0          0   APIC ICR read retries
RES:     942973    2039249    1600588    1481496   Rescheduling interrupts
CAL:         34        111        124        117   Function call interrupts
TLB:      84691     108114      47921      14084   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:       2742       2742       2742       2742   Machine check polls
ERR:          0
MIS:          0

Как видно из приведенных данных - только net5 более-менее равномерно распределяет прерывания (и то на CPU0 их больше), а остальные (с net1 по net4) как-то слишком уж предпочитают CPU0 - на нем на каждой сетевой почти в 200 раз больше прерываний, чем на остальных процессорах.

Хотелось бы понять, почему это происходит, и как это можно побороть.

net5 - Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
net1-4 - Intel Corporation 82576 Gigabit Network Connection (rev 01), объединены в bond

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

Прорицаю сборку дебажного

Прорицаю сборку дебажного ядра ....

ибо:

"Распределение осуществляется на базе расчета хеш функции (остаток от деления) от совокупности таких данных: protocol, source and destination IP, and source and destination port. Технология называется: Receive-side scaling (RSS). В документации написано, что программируема, тоесть теоретически можно выполнять расчет хеш функции например, на базе мак адресов и номеров вланов."

П.С а у тебя точно интел ?

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

slepnoga написал(а): Прорицаю

slepnoga написал(а):
Прорицаю сборку дебажного ядра ....

Ой, не хочется...

slepnoga написал(а):
ибо:

"Распределение осуществляется на базе расчета хеш функции (остаток от деления) от совокупности таких данных: protocol, source and destination IP, and source and destination port. Технология называется: Receive-side scaling (RSS). В документации написано, что программируема, тоесть теоретически можно выполнять расчет хеш функции например, на базе мак адресов и номеров вланов."

Стоп-стоп-стоп...

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

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

Единственное, что может быть - способами распределения можно управлять при помощи ethtool.

slepnoga написал(а):
П.С а у тебя точно интел ?

По крайней мере, lspci говорит именно так, и драйвера собраны именно под эти сетевушки

Стоп-стоп-стоп...Я всю жизнь

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

Милай чиловик, нету больше железного железа из железа, все вокруг давно уже software defunide hardware/networks/storage/brain/hand/sex/ ........

Поэтому нормальная интеловская сетевая представляет собой специализированный микроконтроллер/микрокомпьютер со своей рамой ос/прошивкой, асиком и процом к этому асику. Или ты думаешь, что все навороты вроде tso multicast и hardware mac acl сделаны путем выжигания связей в плис'ке ? Разочарую - это прошивка, т.е блоб. Плюс интела в том, что блоб нормальный, айсик крутой и ethtool может/умеет писать в регистры ппзу карты, ну и ко всему великолепию интеля выкладываю sdk для писания дополнений.
Поэтому да, __карта__ считает хеш пакета и решает на какой irq его засунуть....

П.С
вот сделать подсчет хешей на железке можно ( и это дешевле) - но у интела оно программируемое ( на тему от чего именно считать хеш .

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

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

slepnoga

slepnoga написал(а):
Стоп-стоп-стоп...
Я всю жизнь считал, что распределение пакетов в сетевушке по разным прерываниям - сугубо аппаратная задача самой сетевушки.
Ведь для того, чтобы ядро что-то сделало для анализа протокола и адреса - этот пакет должен в ядро попасть, т.е. прерывание уже произойдет.
Единственное, что может быть - способами распределения можно управлять при помощи ethtool.

Милай чиловик, нету больше железного железа из железа, все вокруг давно уже software defunide hardware/networks/storage/brain/hand/sex/ ........

Поэтому нормальная интеловская сетевая представляет собой специализированный микроконтроллер/микрокомпьютер со своей рамой ос/прошивкой, асиком и процом к этому асику. Или ты думаешь, что все навороты вроде tso multicast и hardware mac acl сделаны путем выжигания связей в плис'ке ? Разочарую - это прошивка, т.е блоб. Плюс интела в том, что блоб нормальный, айсик крутой и ethtool может/умеет писать в регистры ппзу карты, ну и ко всему великолепию интеля выкладываю sdk для писания дополнений.
Поэтому да, __карта__ считает хеш пакета и решает на какой irq его засунуть....

Т.е. я правильно считаю. "Аппаратное" - не обязательно на ПЗУ. Если на карте собран микрокомпьютер - то это все равно аппаратная часть карты.

Разговор ведь зашел о пересборке ядра :)

slepnoga написал(а):
П.С
вот сделать подсчет хешей на железке можно ( и это дешевле) - но у интела оно программируемое ( на тему от чего именно считать хеш .

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

Пакетов без IP там не должно быть. Но это в теории. Трафик внешний, поэтому там может быть вообще всё, что угодно.

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

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".