Изпечатай

[Xalax]

Ситуацията е следната:
Процесори: 2хDual core Xeon със HT
NIC: 4хIntel Gigabit.
Всички прекъсвания генерирани от дадена мрежова карта се обработват от 1 определен процесор (освен ако irqbalance не промени процесора). Ако върху мрежовата карта се приложат някакви дисциплини за контролиране на трафика, то този процесор се натоварва в зависимост от PPS и големината на трафика и съответно се "появява" ksoftirqd/x.

Мисля си да обединя 3 от мрежовите карти в bridge чрез brctl и върху brиdge-а приложа въпросните дисциплини за контролиране на трафика.
Изрових гугъла и неможах да намеря информация относно:
Ще остане ли обработката на прекъсванията  от тези карти върху различни процесори или просто новият bridge ще се използва един единствен процесор ?
Някой правил ли е подобни проби и има ли наблюдения върху подобни разпределения на прекъсванията ?

[tarator]

Какво общо има bridge-a с прекъсванията? Двете се обработват на съвсем различни нива.

[gat3way]

Във връзка с това, ако драйверите за ethernet контролерите ти позволяват NAPI, възползвай се. Това е polling механизъм, при който не се "вдига" веднага функцията, обработваща прекъсването, всъщност такова не се вдига освен на определен интервал от време. Тогава NAPI функцията се изпълнява и обира каквото има по разни queues и си се занимава там с цял един куп пристигнали и асоцирани с устройството sk_buffs. При интензивен трафик, това доста помага при CPU натоварването, генерирано от interrupts. A щом се стига дотам ksoftirqd да почне да товари машината повечко...значи нещата не са много на добре '>

И как ksoftirqd се появява? Той би следвало да си е там, просто да дреме ако няма натоварване. Щом е running през повечето време...значи дам, не е хубава тая работа '>

[zeridon]

Освен NAPI и за в двете посоки друго което ще ти помогне е да разпределиш всяка мрежова карта върху отделно ядро.

Добро начало е: http://www.cs.uwaterloo.ca/~brecht/servers/apic/SMP-affinity.txt

Цитат

- "balance" out multiple NICs in a multi-processor machine.  By tying a single   NIC to a single CPU, you should be able to scale the amount of traffic   your server can handle nicely.

[Xalax]

tarator,
точно ей това тук много не ми е ясно.
Според това до колко разбирам, като почне да се шепва трафика, процесора асоцииран с мрежовата карта почва да не смогва и при усилен трафик и ksoftirqd почва да "обира" новопристигналите пакети (тук може и да греша).
Когато направиш бридж и върху него приложиш шейпване, то тогава самотошейпване ще бъде ли разпределено върху всичките процесори занимаващи се с прекъсванията от мрежовите карти в този бридж? Или просто пак ще се изпълнява от 1 процесор ?

gat3way,
под появяване имах в предвид, че започва да отнема сериозно време на процесора. Иначе при нормална работа, ksoftirqd/x си седи като процес.
Благодаря ти за препоръката. Не съм се занимавал с това NAPI и нямам изобщо представа за какво става въпрос и дали дриверите (които са си от дистрибуцията на федора) поддържат NAPI.

Zeridon,
Ще разчета подробно сайта и нета относно NAPI и ще видя какво може да ми е в помощ.

Благодаря Ви още веднъж за отговорите.

[gat3way]

Принципно, голяма част от gigabit ethernet драйверите подържат NAPI, примерно интел-ските и broadcom-ските. За 100мбит-ови карти не чак толкова (а и там се очаква процесорите да се справят с разните interrupt hogs явно). Software interrupts (softirqs) не би трябвало да имат нещо общо с QoS дисциплините, но не гарантирам 100%, просто така мисля.

"Самото шейпване" няма да бъде разпределено върху всички процесори, поне от гледна точка на паралелизъм, не мисля, просто няма отделен kernel thread, работещ върху всеки процесор и занимаващ се с това, подобно на ksoftirqd/x. Но вероятно работата, асоцирана с шейпването, ще се изпълнява на различен процесор в определено време, предполагам де '>

"bridge" интерфейсът не е точно етернет-ски такъв...смисъл че за него не се вдига специално прекъсване (няма и как) за всеки пристигнал пакет, това си става индивидуално за всеки етернет интерфейс, така че в това отношение няма разлика. bridging-a е просто едно ниво на абстракция в цялата работа, така да се каже...

А иначе (спекулирам с това), броят на прекъсванията може да скочи, защото когато направиш bridge, вкарваш бридж-натите контролери в promiscuous режим и съвсем на теория, би следвало да се вдигат повече прекъсвания. Това е защото самите контролери, на хардуерно ниво, не са ли в promiscuous режим, пристигне ли фрейм дето не е адресиран за тях, не вдигат прекъсване.

Забавното е че смяната на МАК адрес (с ifconfig) при някои мрежови карти става точно така - хардуера не го подържа като функция, затова драйверът се изхитрява и минава в promiscuous mode, и почва да поема само фреймове с новия dst mac. Малко е грубо така, ама тва е '>

[Xalax]

Цитат (zeridon @ Дек. 06 2007,12:38)

Освен NAPI и за в двете посоки друго което ще ти помогне е да разпределиш всяка мрежова карта върху отделно ядро. Добро начало е: http://www.cs.uwaterloo.ca/~brecht/servers/apic/SMP-affinity.txt Цитат - "balance" out multiple NICs in a multi-processor machine.  By tying a single   NIC to a single CPU, you should be able to scale the amount of traffic   your server can handle nicely.

Zeridon,
Много ти благодаря.
Това с smp_affinity не го знаех. Свърши добра работа!
Поне засега, резултатите са добри '>

[zeridon]

Сподели с бедните нещастници '> как си го направил и какво е точно подобрението.

Аз лично ще се радвам на:
 * някакви статистики от преди това (PPS, Mbit/s, IRQ/s)
 * някакви статистики след това (--//--)

Също и малко лични наблюдения от към responsiveness на машината не вярвам някой да откаже.

Друго което ми идва в момента на акъла е ... какво ти е HZ-то на машината (т.е. jiffies колко имаш :П) Постигал съм учудващо добри резултати със HZ=250 s 1000 вече почва да се поебава малко.

[gat3way]

Това много зависи от процесора '>

[Xalax]

Цитат (zeridon @ Дек. 10 2007,21:56)

Сподели с бедните нещастници '> как си го направил и какво е точно подобрението. Аз лично ще се радвам на:  * някакви статистики от преди това (PPS, Mbit/s, IRQ/s)  * някакви статистики след това (--//--) Също и малко лични наблюдения от към responsiveness на машината не вярвам някой да откаже. Друго което ми идва в момента на акъла е ... какво ти е HZ-то на машината (т.е. jiffies колко имаш :П) Постигал съм учудващо добри резултати със HZ=250 s 1000 вече почва да се поебава малко.

Здрасти,
не съм много навътре със такъв фин контрол на линукс. Но пък от друга страна ми доста интересно да го разчовъркам това.

Та по въпроса, не съм замервал като цяло перформънса на машината.

Засега успях да поекспериментирам с прекъсванията.
Интересното е, че ksoftirqd се вдига значително повече върху процесорите на които е разпределена мрежовата карта (отколкото когато е върху 1 процеосор). Или като цяло, може така да ми се струва, тъй като ТОП повечко ksoftirqd отгоре. Ще имам по-точно данни, като поработи машината малко повечко и мога да видя колко от CPU time е разпределен върху ksoftirqd.

Другото което е интересно, че пинговете през машината паднаха с около 20-30% при разпределяне на прекъсванията върху повече от един процесор.

Това което не трябва да се прави е да се рапределят прекъсванията между процесори които не са в едно ядро.
Пинговете през машината се вдигат значително.

Машината е следната:

Примерен код

processor       : 0 vendor_id       : GenuineIntel cpu family      : 15 model           : 6 model name      : Intel(R) Xeon(TM) CPU 2.66GHz stepping        : 4 cpu MHz         : 2656.000 cache size      : 2048 KB physical id     : 0 siblings        : 4 core id         : 0 cpu cores       : 2 fdiv_bug        : no hlt_bug         : no f00f_bug        : no coma_bug        : no fpu             : yes fpu_exception   : yes cpuid level     : 6 wp              : yes flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips        : 5323.96 clflush size    : 64 processor       : 1 vendor_id       : GenuineIntel cpu family      : 15 model           : 6 model name      : Intel(R) Xeon(TM) CPU 2.66GHz stepping        : 4 cpu MHz         : 2656.000 cache size      : 2048 KB physical id     : 0 siblings        : 4 core id         : 0 cpu cores       : 2 fdiv_bug        : no hlt_bug         : no f00f_bug        : no coma_bug        : no fpu             : yes fpu_exception   : yes cpuid level     : 6 wp              : yes flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips        : 5320.02 clflush size    : 64 processor       : 2 vendor_id       : GenuineIntel cpu family      : 15 model           : 6 model name      : Intel(R) Xeon(TM) CPU 2.66GHz stepping        : 4 cpu MHz         : 2656.000 cache size      : 2048 KB physical id     : 0 siblings        : 4 core id         : 1 cpu cores       : 2 fdiv_bug        : no hlt_bug         : no f00f_bug        : no coma_bug        : no fpu             : yes fpu_exception   : yes cpuid level     : 6 wp              : yes flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips        : 5320.07 clflush size    : 64 processor       : 3 vendor_id       : GenuineIntel cpu family      : 15 model           : 6 model name      : Intel(R) Xeon(TM) CPU 2.66GHz stepping        : 4 cpu MHz         : 2656.000 cache size      : 2048 KB physical id     : 0 siblings        : 4 core id         : 1 cpu cores       : 2 fdiv_bug        : no hlt_bug         : no f00f_bug        : no coma_bug        : no fpu             : yes fpu_exception   : yes cpuid level     : 6 wp              : yes flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips        : 5320.09 clflush size    : 64 processor       : 4 vendor_id       : GenuineIntel cpu family      : 15 model           : 6 model name      : Intel(R) Xeon(TM) CPU 2.66GHz stepping        : 4 cpu MHz         : 2656.000 cache size      : 2048 KB physical id     : 1 siblings        : 4 core id         : 0 cpu cores       : 2 fdiv_bug        : no hlt_bug         : no f00f_bug        : no coma_bug        : no fpu             : yes fpu_exception   : yes cpuid level     : 6 wp              : yes flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips        : 5320.12 clflush size    : 64 processor       : 5 vendor_id       : GenuineIntel cpu family      : 15 model           : 6 model name      : Intel(R) Xeon(TM) CPU 2.66GHz stepping        : 4 cpu MHz         : 2656.000 cache size      : 2048 KB physical id     : 1 siblings        : 4 core id         : 0 cpu cores       : 2 fdiv_bug        : no hlt_bug         : no f00f_bug        : no coma_bug        : no fpu             : yes fpu_exception   : yes cpuid level     : 6 wp              : yes flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips        : 5320.12 clflush size    : 64 processor       : 6 vendor_id       : GenuineIntel cpu family      : 15 model           : 6 model name      : Intel(R) Xeon(TM) CPU 2.66GHz stepping        : 4 cpu MHz         : 2656.000 cache size      : 2048 KB physical id     : 1 siblings        : 4 core id         : 1 cpu cores       : 2 fdiv_bug        : no hlt_bug         : no f00f_bug        : no coma_bug        : no fpu             : yes fpu_exception   : yes cpuid level     : 6 wp              : yes flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips        : 5320.13 clflush size    : 64 processor       : 7 vendor_id       : GenuineIntel cpu family      : 15 model           : 6 model name      : Intel(R) Xeon(TM) CPU 2.66GHz stepping        : 4 cpu MHz         : 2656.000 cache size      : 2048 KB physical id     : 1 siblings        : 4 core id         : 1 cpu cores       : 2 fdiv_bug        : no hlt_bug         : no f00f_bug        : no coma_bug        : no fpu             : yes fpu_exception   : yes cpuid level     : 6 wp              : yes flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm bogomips        : 5320.11 clflush size    : 64

Тоест идеята е да не разпределяш eth0 на процесор 1 и 3 или  1 и 7 (тогава положението е лошо)

[gat3way]

Това има много просто обяснение. Просто губиш предимствата на кеша.

[Xalax]

Цитат (gat3way @ Дек. 11 2007,00:13)

Това има много просто обяснение. Просто губиш предимствата на кеша.

Mxm
Така си го пишеше и в гугъла. Затова даже е препоръчително да се ползва едно ядро за двете неща.
Всъщност, експериментирах и така :етх0 и етх1 в едно ядро. Но нещо не ми хареса. Сега тепърва ще продължа с експериментите. Както ще поработя и върху някой финни настройки на самите мрежови карти относно буферирания, брой прекъсвания и максимум време за задържане на прекъсванията.

Ще пиша допълнително за резултатите.

Между другото, това с НАПИ нещо немога да намеря добра информация в нета. Явно не търся правилно.
Но пише, че ако драйвера поддържа НАПИ (което е така за е1000), то се ползва по подразбиране. Имате ли наблюдения за това ?

[gat3way]

Цитат

gat3way:/# grep NAPI /usr/src/linux-2.6.22/.config # CONFIG_TULIP_NAPI is not set # CONFIG_PCNET32_NAPI is not set # CONFIG_AMD8111E_NAPI is not set # CONFIG_ADAPTEC_STARFIRE_NAPI is not set # CONFIG_FORCEDETH_NAPI is not set # CONFIG_VIA_RHINE_NAPI is not set # CONFIG_E1000_NAPI is not set # CONFIG_R8169_NAPI is not set CONFIG_CHELSIO_T1_NAPI=y # CONFIG_IXGB_NAPI is not set # CONFIG_S2IO_NAPI is not set

Това е при мене конфигурацията на ядрото по отношение на тези неща. Не знам как стоят нещата при теб, но има и вариант да няма включена подръжка, въпреки че имаш компилиран такъв драйвер за картата.