История изменений
Исправление i82, (текущая версия) :
Прогнал iperf за 60 секунд, обнулив статистику перезагрузкой. Получилось вот что.
Что касается обработки прерываний от сетевой карты, то она распределяет обработку очередей по процессорам, как это видно по таблице:
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
194: 7128 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth11-TxRx-0
195: 4 7171 0 0 0 0 0 0 IR-PCI-MSI-edge eth11-TxRx-1
196: 4 0 615 0 0 0 0 0 IR-PCI-MSI-edge eth11-TxRx-2
197: 4 0 0 44 0 0 0 0 IR-PCI-MSI-edge eth11-TxRx-3
198: 4 0 0 0 45763 0 0 0 IR-PCI-MSI-edge eth11-TxRx-4
199: 4 0 0 0 0 237906 0 0 IR-PCI-MSI-edge eth11-TxRx-5
200: 7 0 0 0 0 0 568355 0 IR-PCI-MSI-edge eth11-TxRx-6
201: 4 0 0 0 0 0 0 561565 IR-PCI-MSI-edge eth11-TxRx-7
202: 2 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth11
Однако, здесь бросается в глаза неравномерность количества прерываний на процессорах. Я это связываю с тем, что т.к. в моей схеме тестирования D64 генерит трафик, а D63 его ловит и при этом используются постоянные параметры, то модуль сетевой карты, отвечающий за распределение потока по очередям и раскидывающий его по какому-то критерию, в этой схеме даёт неравномерную загрузку очередей...
Что касается статистики softirq, то тут ситуация такая:
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
NET_TX: 395 1 13 0 40 0 2 2
NET_RX: 331584 33902 29998 732 248617 9891414 2740006 2687155
И вот что наблюдается в счётчиках iptables:
Chain PREROUTING (policy ACCEPT 14M packets, 16G bytes)
pkts bytes target prot opt in out source destination
0 0 MARK all -- eth11 any anywhere anywhere cpu 0 MARK set 0xc8
0 0 MARK all -- eth11 any anywhere anywhere cpu 1 MARK set 0xc9
0 0 MARK all -- eth11 any anywhere anywhere cpu 2 MARK set 0xca
0 0 MARK all -- eth11 any anywhere anywhere cpu 3 MARK set 0xcb
0 0 MARK all -- eth11 any anywhere anywhere cpu 4 MARK set 0xcc
5374K 7846M MARK all -- eth11 any anywhere anywhere cpu 5 MARK set 0xcd
0 0 MARK all -- eth11 any anywhere anywhere cpu 6 MARK set 0xce
0 0 MARK all -- eth11 any anywhere anywhere cpu 7 MARK set 0xcf
Chain INPUT (policy ACCEPT 5375K packets, 7738M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 8943K packets, 8124M bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 3568K packets, 207M bytes)
pkts bytes target prot opt in out source destination
166K 9465K MARK all -- any eth11 anywhere anywhere cpu 0 MARK set 0x64
16890 951K MARK all -- any eth11 anywhere anywhere cpu 1 MARK set 0x65
14933 856K MARK all -- any eth11 anywhere anywhere cpu 2 MARK set 0x66
437 25820 MARK all -- any eth11 anywhere anywhere cpu 3 MARK set 0x67
146K 9107K MARK all -- any eth11 anywhere anywhere cpu 4 MARK set 0x68
291K 17M MARK all -- any eth11 anywhere anywhere cpu 5 MARK set 0x69
1478K 85M MARK all -- any eth11 anywhere anywhere cpu 6 MARK set 0x6a
1454K 84M MARK all -- any eth11 anywhere anywhere cpu 7 MARK set 0x6b
Chain POSTROUTING (policy ACCEPT 13M packets, 8330M bytes)
pkts bytes target prot opt in out source destination
Как видно, в OUTPUT какое-никакое распределение есть. Однако, в PREROUTING совсем всё печально - обработка в один поток :(
Исходная версия i82, :
Прогнал iperf за 60 секунд, обнулив статистику перезагрузкой. Получилось вот что.
Что касается обработки прерываний от сетевой карты, то она распределяет обработку очередей по процессорам, как это видно по таблице:
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
194: 7128 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth11-TxRx-0
195: 4 7171 0 0 0 0 0 0 IR-PCI-MSI-edge eth11-TxRx-1
196: 4 0 615 0 0 0 0 0 IR-PCI-MSI-edge eth11-TxRx-2
197: 4 0 0 44 0 0 0 0 IR-PCI-MSI-edge eth11-TxRx-3
198: 4 0 0 0 45763 0 0 0 IR-PCI-MSI-edge eth11-TxRx-4
199: 4 0 0 0 0 237906 0 0 IR-PCI-MSI-edge eth11-TxRx-5
200: 7 0 0 0 0 0 568355 0 IR-PCI-MSI-edge eth11-TxRx-6
201: 4 0 0 0 0 0 0 561565 IR-PCI-MSI-edge eth11-TxRx-7
202: 2 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth11
Однако, здесь бросается в глаза неравномерность количества прерываний на процессорах. Я это связываю с тем, что т.к. в моей схеме тестирования D64 генерит трафик, а D63 его ловит и при этом используются постоянные параметры, то модуль сетевой карты, отвечающий за распределение потока по очередям и раскидывающий его по какому-то критерию, в этой схеме даёт неравномерную загрузку очередей...
Что касается статистики softirq, то тут ситуация такая:
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
NET_TX: 395 1 13 0 40 0 2 2
NET_RX: 331584 33902 29998 732 248617 9891414 2740006 2687155
И вот что наблюдается в счётчиках iptables:
Chain PREROUTING (policy ACCEPT 14M packets, 16G bytes)
pkts bytes target prot opt in out source destination
0 0 MARK all -- eth11 any anywhere anywhere cpu 0 MARK set 0xc8
0 0 MARK all -- eth11 any anywhere anywhere cpu 1 MARK set 0xc9
0 0 MARK all -- eth11 any anywhere anywhere cpu 2 MARK set 0xca
0 0 MARK all -- eth11 any anywhere anywhere cpu 3 MARK set 0xcb
0 0 MARK all -- eth11 any anywhere anywhere cpu 4 MARK set 0xcc
5374K 7846M MARK all -- eth11 any anywhere anywhere cpu 5 MARK set 0xcd
0 0 MARK all -- eth11 any anywhere anywhere cpu 6 MARK set 0xce
0 0 MARK all -- eth11 any anywhere anywhere cpu 7 MARK set 0xcf
Chain INPUT (policy ACCEPT 5375K packets, 7738M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 8943K packets, 8124M bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 3568K packets, 207M bytes)
pkts bytes target prot opt in out source destination
166K 9465K MARK all -- any eth11 anywhere anywhere cpu 0 MARK set 0x64
16890 951K MARK all -- any eth11 anywhere anywhere cpu 1 MARK set 0x65
14933 856K MARK all -- any eth11 anywhere anywhere cpu 2 MARK set 0x66
437 25820 MARK all -- any eth11 anywhere anywhere cpu 3 MARK set 0x67
146K 9107K MARK all -- any eth11 anywhere anywhere cpu 4 MARK set 0x68
291K 17M MARK all -- any eth11 anywhere anywhere cpu 5 MARK set 0x69
1478K 85M MARK all -- any eth11 anywhere anywhere cpu 6 MARK set 0x6a
1454K 84M MARK all -- any eth11 anywhere anywhere cpu 7 MARK set 0x6b
Chain POSTROUTING (policy ACCEPT 13M packets, 8330M bytes)
pkts bytes target prot opt in out source destination
Как видно, в OUTPUT какое-никакое распределение есть. Однако, в PREROUTING совсем всё печально - обработка в один поток :(