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

Распределение прерываний на Intel 82576

Имеется 2 портовая карточка на чипсете 82576. На каждом порту организовано по две очереди rx. На одном из интерфейсов висит pppoe, соответственно, ip адресов на нем нет.

Проблема в том, что не балансируются прерывания по очередям на pppoe интерфейсе. Но втором интерфейсе (он смотрит наружу) - все нормально. Я выяснил, что прерывания делятся на основании srcIP. Можно ли как-то заставить карточку load balancing отрабатывать по mac адресам?

 

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


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

А как вы это проверили?

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


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

А как вы это проверили?
cat /proc/interrupts и mpstat

Поднял ip на интерфейсе и с двух машин сделал ping -f. Сверился: прерывания делятся.

 

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


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

Имеется 2 портовая карточка на чипсете 82576. На каждом порту организовано по две очереди rx. На одном из интерфейсов висит pppoe, соответственно, ip адресов на нем нет.

Проблема в том, что не балансируются прерывания по очередям на pppoe интерфейсе. Но втором интерфейсе (он смотрит наружу) - все нормально. Я выяснил, что прерывания делятся на основании srcIP. Можно ли как-то заставить карточку load balancing отрабатывать по mac адресам?

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

Изменено пользователем nag-f

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


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

Наблюдаю идентичную ситуацию на bras-е.

 

Имеется 2 портовая карточка на чипсете 82576. На каждом порту организовано по две очереди rx. На одном из интерфейсов висит pppoe, соответственно, ip адресов на нем нет.
Дуальный ксенон 5520 (гипертрейдинг включен - в итоге 16 ядер) + CentOs 5.4 (ядро 2.6.31.12 x86_64 - ванильное) + дуальная Intel Corporation 82576 Gigabit Network Connection (по 8 TxRx-queue на порт - ) + igb.ko (версии 2.1.9 - options igb InterruptThrottleRate=3,3 IntMode=2,2 RSS=8,8 QueuePairs=1,1).

Irq_balance выключен наглухо. Очереди прибиты к ядрам посредством smp_affinity.

/bin/echo 1 >    /proc/irq/`cat /proc/interrupts | grep 'eth0-TxRx-0' | awk -F \: '{printf "%i", $1}'`/smp_affinity
/bin/echo 2 >    /proc/irq/`cat /proc/interrupts | grep 'eth0-TxRx-1' | awk -F \: '{printf "%i", $1}'`/smp_affinity
/bin/echo 4 >    /proc/irq/`cat /proc/interrupts | grep 'eth0-TxRx-2' | awk -F \: '{printf "%i", $1}'`/smp_affinity
/bin/echo 8 >    /proc/irq/`cat /proc/interrupts | grep 'eth0-TxRx-3' | awk -F \: '{printf "%i", $1}'`/smp_affinity
/bin/echo 10 >   /proc/irq/`cat /proc/interrupts | grep 'eth1-TxRx-0' | awk -F \: '{printf "%i", $1}'`/smp_affinity
/bin/echo 20 >   /proc/irq/`cat /proc/interrupts | grep 'eth1-TxRx-1' | awk -F \: '{printf "%i", $1}'`/smp_affinity
/bin/echo 40 >   /proc/irq/`cat /proc/interrupts | grep 'eth1-TxRx-2' | awk -F \: '{printf "%i", $1}'`/smp_affinity
/bin/echo 80 >   /proc/irq/`cat /proc/interrupts | grep 'eth1-TxRx-3' | awk -F \: '{printf "%i", $1}'`/smp_affinity
/bin/echo 100 >  /proc/irq/`cat /proc/interrupts | grep 'eth0-TxRx-4' | awk -F \: '{printf "%i", $1}'`/smp_affinity
/bin/echo 200 >  /proc/irq/`cat /proc/interrupts | grep 'eth0-TxRx-5' | awk -F \: '{printf "%i", $1}'`/smp_affinity
/bin/echo 400 >  /proc/irq/`cat /proc/interrupts | grep 'eth0-TxRx-6' | awk -F \: '{printf "%i", $1}'`/smp_affinity
/bin/echo 800 >  /proc/irq/`cat /proc/interrupts | grep 'eth0-TxRx-7' | awk -F \: '{printf "%i", $1}'`/smp_affinity
/bin/echo 1000 > /proc/irq/`cat /proc/interrupts | grep 'eth1-TxRx-4' | awk -F \: '{printf "%i", $1}'`/smp_affinity
/bin/echo 2000 > /proc/irq/`cat /proc/interrupts | grep 'eth1-TxRx-5' | awk -F \: '{printf "%i", $1}'`/smp_affinity
/bin/echo 4000 > /proc/irq/`cat /proc/interrupts | grep 'eth1-TxRx-6' | awk -F \: '{printf "%i", $1}'`/smp_affinity

Интерфейс eth0 смотрит в сторону Интерента (соответственно на нем имеется IP адрес), а вот eth1 принимает что то около 170 вланов и по ним бегает pppoe (соответственно на на сабинтерфейсах IP адресов нет).

Проблема в том, что не балансируются прерывания по очередям на pppoe интерфейсе. Но втором интерфейсе (он смотрит наружу) - все нормально. Я выяснил, что прерывания делятся на основании srcIP. Можно ли как-то заставить карточку load balancing отрабатывать по mac адресам?
Абсолютно в дырочку! :( То же самое вижу и я.
А как вы это проверили?
Да вот собственно:

[root@zuy /]# cat /proc/interrupts | grep eth
          CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       CPU8       CPU9       CPU10      CPU11      CPU12      CPU13      CPU14      CPU15
58:          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0
59:    9218294          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-0
60:         18    8942303          0          0          0          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-1
61:         18          0    9033240          0          0          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-2
62:         18          0          0    9022986          0          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-3
63:         18          0          0          0          0          0          0          0    8945491          0          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-4
64:         18          0          0          0          0          0          0          0          0    9132319          0          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-5
65:         22          0          0          0          0          0          0          0          0          0   10131884          0          0          0          0          0   PCI-MSI-edge      eth0-TxRx-6
66:         18          0          0          0          0          0          0          0          0          0          0    8976738          0          0          0          0   PCI-MSI-edge      eth0-TxRx-7
71:          2          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth1
72:         16          0          0          0   10259679          0          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth1-TxRx-0
73:         16          0          0          0          0   10076368          0          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth1-TxRx-1
74:         19          0          0          0          0          0       3136          0          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth1-TxRx-2
75:         16          0          0          0          0          0          0       3039          0          0          0          0          0          0          0          0   PCI-MSI-edge      eth1-TxRx-3
76:         16          0          0          0          0          0          0          0          0          0          0          0       2948          0          0          0   PCI-MSI-edge      eth1-TxRx-4
77:         16          0          0          0          0          0          0          0          0          0          0          0          0       3163          0          0   PCI-MSI-edge      eth1-TxRx-5
78:         16          0          0          0          0          0          0          0          0          0          0          0          0          0       2937          0   PCI-MSI-edge      eth1-TxRx-6
79:         16          0          0          0          0          0          0          0          0          0          0          0          0          0          0       2929   PCI-MSI-edge      eth1-TxRx-7

[root@zuy /]# ethtool -S eth0 | grep _bytes
    rx_bytes: 248889911172
    tx_bytes: 140271084072
    tx_queue_0_bytes: 4526577472
    tx_queue_1_bytes: 1150610
    tx_queue_2_bytes: 875085
    tx_queue_3_bytes: 3608583
    tx_queue_4_bytes: 3155833
    tx_queue_5_bytes: 2758101
    tx_queue_6_bytes: 134059687880
    tx_queue_7_bytes: 881538
    rx_queue_0_bytes: 32438700498
    rx_queue_1_bytes: 31211398512
    rx_queue_2_bytes: 32025300798
    rx_queue_3_bytes: 31087538129
    rx_queue_4_bytes: 29303373992
    rx_queue_5_bytes: 32237290730
    rx_queue_6_bytes: 30406620695
    rx_queue_7_bytes: 28990104018

[root@zuy /]# ethtool -S eth1 | grep _bytes
    rx_bytes: 143713935589
    tx_bytes: 250411229236
    tx_queue_0_bytes: 0
    tx_queue_1_bytes: 248096446088
    tx_queue_2_bytes: 0
    tx_queue_3_bytes: 0
    tx_queue_4_bytes: 0
    tx_queue_5_bytes: 0
    tx_queue_6_bytes: 0
    tx_queue_7_bytes: 0
    rx_queue_0_bytes: 141532905198
    rx_queue_1_bytes: 20965
    rx_queue_2_bytes: 77990
    rx_queue_3_bytes: 37958
    rx_queue_4_bytes: 18433
    rx_queue_5_bytes: 34080
    rx_queue_6_bytes: 11499
    rx_queue_7_bytes: 13824

Т.е. явно наблюдается картина, что на интерфейсе eth0 (где ходит ip трафик) rx размазывается по очередям нормально, с tx-ом наблюдается какая то фигня (но вроде бы как не совсем критичная). А вот на интерфейсе eth1 (где ходит pppoe) все очень плохо - одна очередь работает на прием, другая на передачу, остальные нервно курят в сторонке - и это сильно напрягает. :(

Не совсем так. Распределение осуществляется на базе расчета хеш функции (остаток от деления) от совокупности таких данных: protocol, source and destination IP, and source and destination port.
Хм... Судя по изречениям Intel-а - "Receive Side Scaling (RSS) is enabled, all of the receive data processing for a particular TCP connection is shared across multiple processors or processor cores." - Т.е. RSS пригоден только для TCP/IP трафика? И только на прием?

А как же быть с передачей? - В частности, вот кусок вывода ethtool-а c другого сервера (у него такая же сетевая карта, идентичный драйвер и конфигурация оного, на обеих интерфейсах есть IP, и сквозь него бегает IP трафик):

[root@bsr1 ~]# ethtool -S eth0 | grep _bytes
    rx_bytes: 3670510559543
    tx_bytes: 1841567429678
    tx_queue_0_bytes: 445674834217
    tx_queue_1_bytes: 461627912135
    tx_queue_2_bytes: 462179616243
    tx_queue_3_bytes: 448597195799
    rx_queue_0_bytes: 924775109855
    rx_queue_1_bytes: 887583186910
    rx_queue_2_bytes: 916779560435
    rx_queue_3_bytes: 924832940264

[root@bsr1 ~]# ethtool -S eth1 | grep _bytes
    rx_bytes: 1858657582592
    tx_bytes: 3492732326572
    tx_queue_0_bytes: 889990733253
    tx_queue_1_bytes: 851068298298
    tx_queue_2_bytes: 841395361424
    tx_queue_3_bytes: 889604189256
    rx_queue_0_bytes: 452506942083
    rx_queue_1_bytes: 468225803321
    rx_queue_2_bytes: 468736301066
    rx_queue_3_bytes: 453538118272

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

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

 

Буду благодарен за любую информацию по данному вопросу.

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


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

Т.е. за расчет этой хеш функции отвечает драйвер или же драйвер "камень" сетевой карты программирует?

 

Буду благодарен за любую информацию по данному вопросу.

Я несколько неоднозначно выразился. Речь ишла о теоретической (принципиальной) возможности реализовать такой функционал на аппаратном уровне.

Мне трудно судить, что у вас на доступе, но единственное, что можно вам посоветовать - уходить от PPPoE или от тунелирования в принципе :)

 

P.S Славянск симпатичный город :)

Изменено пользователем nag-f

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


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

Jugernault, аппаратно эту проблему похоже не решить. Можно попробовать программный RPS: http://forum.nag.ru/forum/index.php?showtopic=55649, результаты очень хорошие.

 

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


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

Jugernault, аппаратно эту проблему похоже не решить. Можно попробовать программный RPS: http://forum.nag.ru/forum/index.php?showtopic=55649, результаты очень хорошие.

+ XPS http://lwn.net/Articles/363338/

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


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

аппаратно эту проблему похоже не решить
Угумс :/
The 82576 hash function follows Microsoft* definition.
Наверно можно сделать балансинг по 24-м MAC'ам, но кому это надо :)
Each of the 24 MAC address filters can be associated with a VF/VM. The VIND field in the Receive Address High (RAH) register determines the target VM. Packets that do not match any of the MAC filters (such as promiscuous) are assigned with the default VT.
Изменено пользователем voron

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


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

Я несколько неоднозначно выразился. Речь ишла о теоретической (принципиальной) возможности реализовать такой функционал на аппаратном уровне.
Проштудировал, с пристрастием, мануал по 28576 - вариантов подружить алгоритм выбора очереди с pppoe не вижу. В процессе чтения в голову лезли мысли о виртуализации, однако похоже что данная карта может подать на одну VM не более 32-х вланов - т.е. у тут облом.
Мне трудно судить, что у вас на доступе, но единственное, что можно вам посоветовать - уходить от PPPoE или от тунелирования в принципе :)
Пока не время, вернее всему свое время. :)
Мне трудно судить, что у вас на доступе, но единственное, что можно вам посоветовать - уходить от PPPoE или от тунелирования в принципе :)

P.S Славянск симпатичный город :)

Будете у нас на "Колыме"...

 

Jugernault, аппаратно эту проблему похоже не решить. Можно попробовать программный RPS: http://forum.nag.ru/forum/index.php?showtopic=55649, результаты очень хорошие.
Спасибо за ссылку, однако в продакшн такое ставить несколько боязно.

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


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

Господа, мы тут с вами об RSS беседовали. Однако насколько я понимаю он выполняет балансировку по входящим очередям.

А как быть с исходящими?

 

В частности в igb-2.1.9 имеются вот такие вот строки:

 

#ifdef CONFIG_NETDEVICES_MULTIQUEUE
#define HAVE_TX_MQ
#endif

и

#ifdef CONFIG_NETDEVICES_MULTIQUEUE

        if (adapter->num_tx_queues > 1)
                netdev->features |= NETIF_F_MULTI_QUEUE;
        else
                netdev->features &= ~NETIF_F_MULTI_QUEUE;
#endif

 

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

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

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


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

Господа, мы тут с вами об RSS беседовали. Однако насколько я понимаю он выполняет балансировку по входящим очередям.

А как быть с исходящими?

XPS решает проблему (программно), но ему еще далек даже до уровня RPS

 

Возникает вопрос - CONFIG_NETDEVICES_MULTIQUEUE должно браться из ядра, но его там нет (2.6.31.12) и данный код не выполняется, как быть?
http://git.kernel.org/?p=linux/kernel/git/...564671aa7c0fd27

 

 

 

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


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

Привет всем.

 

uname -a
FreeBSD nas1.local.ua 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #2: Mon Apr 12 19:23:34 EEST 2010     root@:/usr/obj/usr/src/sys/NAS  amd64

Мужики спасайте. Есть сервер с картой на 576 чипе. На этой карте поднято 10 вланов. Сегодня пришлось убрать два влана.

Что я сделал.

ifconfig vlan31 destroy

после этого сервер вроде завис, но через 30 секунд отпустило, потом решил убрать еще один влан

ifconfig vlan32 destroy

но спустя 2 минуты достучаться до сервера не смог.

Подключил к серверу клаву и монитор, перезагрузил. После этого процесс загрузки остановился на старте named, подумал, подумал и вывалил ошибку с матюками на igb и interrupt irq260 и ушол в ребут опять. Загрузился в сингл моде, пересобрал ядро с драйвером (до этого драйвер грузился модулем), опять тоже. Поубирал тюнинг sysctl и loader.conf - не помогло. Потом вспомнил, что где-то читал на форуме, что был глюк ели вытянуть и втыкнуть кабель в эту сетевушку, то линк уже не поднимается. Попробовал - линк поднялся. И тут меня осенило, а что если я загружусь без включеных кабелей, а после полной загрузки включу кабеля в карту и не поверите помогло.

И что теперь делать даже незнаю, сервер могу дергать только ночью. Помогите советом.

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

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


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

Добрый день ,форум, нужна помощь.

Кто-нибудь сталкивался с проблемой не разруливания прерывания по нескольким CPU от 1-го устройства?

 

Предыстория: Есть 3 сервера HP ,Xeon 5550 с Intel 82576 на них и driver igb 2.1.9 (2.6.31-gentoo-r6)

 

ethtool -i eth2

driver: igb

version: 2.1.9

firmware-version: 1.2-1

bus-info: 0000:19:00.0

 

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

cat /proc/interrupts

CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7

0: 921 914 7654 1114 955 926 7725 1155 IO-APIC-edge timer

1: 1 1 1 1 1 1 1 1 IO-APIC-edge i8042

8: 15 14 14 14 15 14 14 15 IO-APIC-edge rtc0

9: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi acpi

12: 1 0 1 0 1 0 0 1 IO-APIC-edge i8042

14: 6 5 5 6 3 4 6 7 IO-APIC-edge ide0

15: 0 0 0 0 0 0 0 0 IO-APIC-edge ide1

16: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2

17: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb3

18: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4

19: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb5

22: 12 11 12 11 12 12 12 12 IO-APIC-fasteoi uhci_hcd:usb6

39: 253723 184 177 177 254037 180 179 178 PCI-MSI-edge cciss0

41: 1 0 3 0 0 0 3 0 PCI-MSI-edge eth2

42: 145323907 1 5 7 145303542 1 3 9 PCI-MSI-edge eth2-TxRx-0

 

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

cat /proc/irq/42/smp_affinity

11

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

Те прерывания падают на 0 и 4 CPU как и следует из smp_affinity

 

(А теперь история: )

 

Есть еще 2 сервера:

 

Supermicro X8DTH-6 / 2 CPU*4 cores Xeon 5550 / NC522SFP -10Ge NIC от Qlogic, которую предлагает всем HP, обновил прошивку и драйвер до последней доступной.

Ядра: 2.6.31-gentoo-r10, 2.6.32-gentoo-r7, 2.6.34-rc7-git2

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

driver: nx_nic

version: 4.0.520

firmware-version: 4.0.520

bus-info: 0000:84:00.0

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

 

и

 

 

Supermicro X8ST3-F с Core I7 4 cores с 82576 с igb 2.1.9 от Intel получил ту же самую картину. Ядро 2.6.32-gentoo-r7, на старом 2.6.31-r6 тоже пробовал не получается.

 

MSI/MSI-x в ядро включено, Драйвера загружал и с поддержкой MSI и с поддержкой MSI-X и в legasy mode. Проблема в том, что на этих серваках я не могу назначить что бы прерывания распределялись на 2 ядра одновременно, все уходит на 1.

 

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

cat /proc/interrupts

 

38: 0 0 0 0 PCI-MSI-edge eth3

39: 0 0 123834 0 PCI-MSI-edge eth3-TxRx-0

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

 

cat /proc/irq/39/smp_affinity

000f

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

 

ethtool -i eth3

driver: igb

version: 2.1.9

firmware-version: 1.2-1

bus-info: 0000:03:00.1

 

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

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


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

не видно очередей!

должно быть что то типа такого

205: 0 0 0 2447027927 0 0 0 0 PCI-MSI-edge eth1-rx-3

206: 0 2213897576 0 0 0 0 111927528 50485137 PCI-MSI-edge eth1-rx-2

207: 0 0 0 0 0 0 556631032 1898846657 PCI-MSI-edge eth1-rx-1

208: 0 0 1512521928 0 0 663735751 0 0 PCI-MSI-edge eth1-TxRx-0

209: 0 0 0 0 0 1 0 0 PCI-MSI-edge eth1

210: 0 0 0 0 216407601 0 0 0 PCI-MSI-edge eth0-rx-3

211: 0 0 3480157 0 11953414 208855880 0 0 PCI-MSI-edge eth0-rx-2

212: 0 3343833 0 8301488 0 0 189793992 25248360 PCI-MSI-edge eth0-rx-1

213: 4103553832 0 0 733570803 7114755 0 0 0 PCI-MSI-edge eth0-TxRx-0

214: 0 0 1 0 0 0 0 0 PCI-MSI-edge eth0

215: 0 0 0 0 0

 

 

/sbin/modprobe igb RSS=4,4 - RSS - задаёт количество очередей

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


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

RSS=4

 

cat /proc/interrupts

CPU0 CPU1 CPU2 CPU3

0: 24 0 0 7222 IO-APIC-edge timer

1: 0 0 0 8 IO-APIC-edge i8042

7: 0 0 0 0 IO-APIC-edge parport0

8: 0 0 0 96 IO-APIC-edge rtc0

9: 0 0 0 0 IO-APIC-fasteoi acpi

14: 0 0 0 0 IO-APIC-edge ide0

15: 0 0 0 0 IO-APIC-edge ide1

19: 0 1417 0 0 IO-APIC-fasteoi ata_piix, ata_piix

23: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2

34: 0 0 0 0 PCI-MSI-edge eth6

35: 605 0 0 0 PCI-MSI-edge eth6-TxRx-0

36: 0 45 0 0 PCI-MSI-edge eth6-TxRx-1

37: 0 451 0 0 PCI-MSI-edge eth6-TxRx-2

38: 0 0 102 0 PCI-MSI-edge eth6-TxRx-3

39: 0 0 3 0 PCI-MSI-edge ioat-msix

40: 3 0 0 0 PCI-MSI-edge ioat-msix

41: 3 0 0 0 PCI-MSI-edge ioat-msix

42: 0 3 0 0 PCI-MSI-edge ioat-msix

43: 0 3 0 0 PCI-MSI-edge ioat-msix

44: 0 0 3 0 PCI-MSI-edge ioat-msix

45: 0 0 3 0 PCI-MSI-edge ioat-msix

46: 0 0 0 3 PCI-MSI-edge ioat-msix

50: 0 0 0 0 PCI-MSI-edge eth3

51: 0 37 0 0 PCI-MSI-edge eth3-TxRx-0

NMI: 0 0 0 0 Non-maskable interrupts

LOC: 3089 2190 2435 810 Local timer interrupts

SPU: 0 0 0 0 Spurious interrupts

PMI: 0 0 0 0 Performance monitoring interrupts

PND: 0 0 0 0 Performance pending work

RES: 4181 4659 4267 2693 Rescheduling interrupts

CAL: 111 112 152 176 Function call interrupts

TLB: 2291 4884 1770 2420 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: 2 2 2 2 Machine check polls

ERR: 3

MIS: 0

 

!!!

cat /proc/irq/35/smp_affinity

000f

 

Но прерывания не ушли на все CPU, хотелось бы получить возможность распределения по всем CPU.

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


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

Разовый запуск irqbalance или форсирование /proc/irq/xx/smp_affinity

0f это значит любой cpu, автоматический выбор.

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


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

irqbalance делает то же самое что я делаю ручками, указывая, что это прерывние должно обрабатываться 1 или n-кол-вом CPU, например я назанчил значение 3 прерыванию 35, значит его должны обрабатывать 0 и 1 CPU, картина не меняется...

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

cat /proc/irq/35/smp_affinity

0003

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

cat /proc/interrupts

CPU0 CPU1 CPU2 CPU3

0: 24 0 0 363786 IO-APIC-edge timer

1: 0 0 0 8 IO-APIC-edge i8042

7: 0 0 0 0 IO-APIC-edge parport0

8: 0 0 0 96 IO-APIC-edge rtc0

9: 0 0 0 0 IO-APIC-fasteoi acpi

14: 0 0 0 0 IO-APIC-edge ide0

15: 0 0 0 0 IO-APIC-edge ide1

19: 0 1657 0 0 IO-APIC-fasteoi ata_piix, ata_piix

23: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2

34: 0 0 0 0 PCI-MSI-edge eth6

35: 415191 0 0 0 PCI-MSI-edge eth6-TxRx-0

36: 0 36113 0 0 PCI-MSI-edge eth6-TxRx-1

37: 0 39484 0 0 PCI-MSI-edge eth6-TxRx-2

38: 0 0 39908 0 PCI-MSI-edge eth6-TxRx-3

39: 0 0 3 0 PCI-MSI-edge ioat-msix

40: 3 0 0 0 PCI-MSI-edge ioat-msix

41: 3 0 0 0 PCI-MSI-edge ioat-msix

42: 0 3 0 0 PCI-MSI-edge ioat-msix

43: 0 3 0 0 PCI-MSI-edge ioat-msix

44: 0 0 3 0 PCI-MSI-edge ioat-msix

45: 0 0 3 0 PCI-MSI-edge ioat-msix

46: 0 0 0 3 PCI-MSI-edge ioat-msix

50: 0 0 0 0 PCI-MSI-edge eth3

51: 0 30895 0 0 PCI-MSI-edge eth3-TxRx-0

NMI: 0 0 0 0 Non-maskable interrupts

LOC: 107249 115609 108038 945 Local timer interrupts

SPU: 0 0 0 0 Spurious interrupts

PMI: 0 0 0 0 Performance monitoring interrupts

PND: 0 0 0 0 Performance pending work

RES: 43657 50418 41032 35870 Rescheduling interrupts

CAL: 111 112 152 176 Function call interrupts

TLB: 2291 4887 1770 2420 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: 208 208 208 208 Machine check polls

ERR: 3

MIS: 0

 

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


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

ещё вроде как некоторые опции в ядре надо выключить, чтобы прерывания "размазались" по всем CPU... иначе на уровне ядра не получится обработать прерывание более чем на 1 CPU....

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


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

например я назанчил значение 3 прерыванию 35, значит его должны обрабатывать 0 и 1 CPU
0 или 1

Если

echo 2 >  /proc/irq/35/smp_affinity

то всё равно ничего не меняется?

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


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

например я назанчил значение 3 прерыванию 35, значит его должны обрабатывать 0 и 1 CPU
0 или 1

Если

echo 2 >  /proc/irq/35/smp_affinity

то всё равно ничего не меняется?

 

1) По-моему, что бы задействовать 0 и 1 CPU все же нужно вводить значение 3.

2) При вводе 2, прерывания все равно отсаются на CPU0.

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


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

Привет всем.

 

uname -a
FreeBSD nas1.local.ua 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #2: Mon Apr 12 19:23:34 EEST 2010     root@:/usr/obj/usr/src/sys/NAS  amd64

Мужики спасайте. Есть сервер с картой на 576 чипе. На этой карте поднято 10 вланов. Сегодня пришлось убрать два влана.

Что я сделал.

ifconfig vlan31 destroy

после этого сервер вроде завис, но через 30 секунд отпустило, потом решил убрать еще один влан

ifconfig vlan32 destroy

но спустя 2 минуты достучаться до сервера не смог.

Подключил к серверу клаву и монитор, перезагрузил. После этого процесс загрузки остановился на старте named, подумал, подумал и вывалил ошибку с матюками на igb и interrupt irq260 и ушол в ребут опять. Загрузился в сингл моде, пересобрал ядро с драйвером (до этого драйвер грузился модулем), опять тоже. Поубирал тюнинг sysctl и loader.conf - не помогло. Потом вспомнил, что где-то читал на форуме, что был глюк ели вытянуть и втыкнуть кабель в эту сетевушку, то линк уже не поднимается. Попробовал - линк поднялся. И тут меня осенило, а что если я загружусь без включеных кабелей, а после полной загрузки включу кабеля в карту и не поверите помогло.

И что теперь делать даже незнаю, сервер могу дергать только ночью. Помогите советом.

тоже есть пробле мка с сетевой...также отключаеш патчкорд-включаеш - и буффер сайз нот авеибл...нужен рубут тогда, дрова вообще не ставили, ОС фря 7.3 сама обнаружила карточку...но когда top - SP получаем

last pid: 51748; load averages: 0.06, 0.12, 0.14 up 0+04:43:27 13:42:29

156 processes: 6 running, 113 sleeping, 13 stopped, 2 zombie, 22 waiting

CPU 0: 0.0% user, 0.0% nice, 4.5% system, 63.6% interrupt, 31.8% idle

CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle

CPU 2: 0.0% user, 0.0% nice, 4.5% system, 13.6% interrupt, 81.8% idle

CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle

Mem: 95M Active, 17M Inact, 115M Wired, 16K Cache, 78M Buf, 573M Free

Swap: 2048M Total, 2048M Free

 

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND

11 root 1 171 ki31 0K 8K CPU3 3 269:20 100.00% idle: cpu3

12 root 1 171 ki31 0K 8K RUN 2 259:33 97.17% idle: cpu2

13 root 1 171 ki31 0K 8K CPU1 1 271:39 95.56% idle: cpu1

30 root 1 -64 - 0K 8K CPU0 0 157:49 69.87% irq16: uhci0+

14 root 1 171 ki31 0K 8K RUN 0 115:51 30.96% idle: cpu0

44 root 1 -68 - 0K 8K WAIT 2 6:35 3.08% irq260: igb1

40 root 1 -68 - 0K 8K WAIT 0 8:11 2.78% irq257: igb0

39 root 1 -68 - 0K 8K WAIT 2 0:48 0.10% irq256: igb0

46 root 1 -68 - 0K 8K - 3 1:06 0.00% igb1 taskq

43 root 1 -68 - 0K 8K WAIT 2 1:03 0.00% irq259: igb1

42 root 1 -68 - 0K 8K - 0 1:01 0.00% igb0 taskq

18 root 1 44 - 0K 8K - 3 0:50 0.00% yarrow

60 root 1 -68 - 0K 8K - 3 0:44 0.00% dummynet

15 root 1 -32 - 0K 8K WAIT 2 0:40 0.00% swi4: clock sio

5 root 1 -68 - 0K 8K sleep 3 0:14 0.00% ng_queue3

4 root 1 -68 - 0K 8K sleep 0 0:14 0.00% ng_queue2

2 root 1 -68 - 0K 8K sleep 3 0:14 0.00% ng_queue0

3 root 1 -68 - 0K 8K sleep 3 0:14 0.00% ng_queue1

59 root 1 8 - 0K 8K pftm 1 0:10 0.00% pfpurge

1140 mysql 18 44 0 458M 71704K ucond 2 0:03 0.00% mysqld

7 root 1 -8 - 0K 8K - 1 0:03 0.00% g_up

49 root 1 -64 - 0K 8K WAIT 0 0:03 0.00% irq19: uhci4++

954 root 1 44 0 9036K 6248K select 1 0:02 0.00% snmpd

кто что посоветует?

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


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

народ хелп..интерупт 72% хоть ты тресни...кто что посоветует?

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

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


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

1) По-моему, что бы задействовать 0 и 1 CPU все же нужно вводить значение 3.
Прерывание будет обрабатываться в 1 момент времени только на одном из CPU. Именно это я имел ввиду под "или"

 

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


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

Join the conversation

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

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

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

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

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

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

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