Linux за българи: Форуми

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

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

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

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

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

Освен 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.

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

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

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

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

Принципно, голяма част от 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. Малко е грубо така, ама тва е

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

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

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

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

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

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