Привязка прерываний к ядру для сетевых карт
IVB 13 декабря, 2013 - 18:06
Всем доброго времени суток.
Возникла задача - привязать прерывания пяти сетевых карт (из которых 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 написал(а):
Я немного не про это. Если Вы обратили внимание - я как раз и использую 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 написал(а): Прорицаю
Ой, не хочется...
Стоп-стоп-стоп...
Я всю жизнь считал, что распределение пакетов в сетевушке по разным прерываниям - сугубо аппаратная задача самой сетевушки.
Ведь для того, чтобы ядро что-то сделало для анализа протокола и адреса - этот пакет должен в ядро попасть, т.е. прерывание уже произойдет.
Единственное, что может быть - способами распределения можно управлять при помощи ethtool.
По крайней мере, lspci говорит именно так, и драйвера собраны именно под эти сетевушки
Стоп-стоп-стоп...Я всю жизнь
Милай чиловик, нету больше железного железа из железа, все вокруг давно уже 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
Т.е. я правильно считаю. "Аппаратное" - не обязательно на ПЗУ. Если на карте собран микрокомпьютер - то это все равно аппаратная часть карты.
Разговор ведь зашел о пересборке ядра :)
Пакетов без IP там не должно быть. Но это в теории. Трафик внешний, поэтому там может быть вообще всё, что угодно.
А за наводку на NAG спасибо, обязательно посмотрю, можно ли в моих сетевушках перепрограммировать алгоритм распределения.