Dotaz: 10 Gbit bidir routing

[Lidumil Všehomír]

Dobrý den, potřeboval bych poradit, jak optimálně vyladit linuxové jádro pro vysoké síťové výkony. Konkrétně mi jde o pps.

Mám tři servery/routery (1 x proc Xeon X5650, 6GB RAM), každý s dvojicí karet Intel Corporation 82599EB 10-Gigabit SFI/SFP+. Na ně jsem nainstaloval debian 6 a dal tam vlastní ořezané vanilla jádro (2.6.38). Z něj jsem odstranil věci, které nebudu potřebovat (od pcmcia ... přes nepoužité FS až po netfilter). Stroje jsem propojil přes optiku a prostřednímu nastavil forwarding, aby mohl fungovat jako provizorní router. Vše mi funguje, všude se dopingnu. Při testu s kopírováním na ftp z /dev/shm do /dev/shm to teoreticky vypadalo vše v pořádku. Stejně tak při použití pktgen a paketů s MTU blízko 1500. Při menších paketech pps stoupne jenom mírně a dále už neroste.

jednosměrně MTU = 1500 - pps = 850 000 MTU = 64 - pps = 960 000

obousměrně MTU = 1500 - pps = 480 000

další detaily:

nejde mi o jumbo frames (už při 1500 to jede okolo 10Gbit), ale právě o pps

snažil jsem se dále ladit výkon sítě dle tohoto článku http://proj.sunet.se/E2E/tcptune.html následující parametry (bezvýsledně)

echo 1 > /proc/sys/net/ipv4/tcp_window_scaling echo 1 > /proc/sys/net/ipv4/tcp_timestamps echo 32000000 > /proc/sys/net/core/rmem_max echo 32000000 > /proc/sys/net/core/wmem_max echo 240000 > /proc/sys/net/core/rmem_default echo 240000 > /proc/sys/net/core/wmem_default echo 9182 174760 32000000 > /proc/sys/net/ipv4/tcp_rmem echo 9182 174760 32000000 > /proc/sys/net/ipv4/tcp_wmem echo 1024000 1400000 2200000 > /proc/sys/net/ipv4/tcp_mem ifconfig eth5 txqueuelen 100000 ifconfig eth5 rxqueuelen 100000

Co se týče jader, tak to samozřejmě mám nastaveno tak, aby každou z dvanácti front na síťové kartě obsluhovalo jedno.

I při polovičním počtu přidělených jader to jede na "maximální výkon". Dnes jsem zkoušel generovat provoz, pomocí 2 karet (rozdělení jader 50:50). Počet paketů byl při 64B paketech na každé cca 540000 celkově to tedy generovalo o něco víc (1080000), ale spokojen nejsem. Potřeboval bych tak 3-5Mpps.

Dle mnoha testů a tuningu, které jsem na internetu našel lze však výkon ještě několikanásobně zvýšit.

http://wenku.baidu.com/view/cfdad666f5335a8102d220f0.html

Co se serverů týče: budou to páteřní routery na kterých poběží bird a za nimi bude hučet několik tisíc serverů (pro zběžnou představu)

Kdyby někoho něco napadlo, tak jsem jedno velké ucho :)

---

---

Odpovědi

[kyytaM]

Vyatta uvadza, ze na svojom najsilnejsom zariadeni da 3M pps. Je to postavene na Debian Squeeze, takze za pokus by mozno stalo to skusit nahodit a porovnat, ci sa ta priepustnost bude lisit (ci to maju lepsie, alebo horsie vytunene :D).

http://www.vyatta.org/downloads pripadne http://www.vyatta.com/download/trial_software

[Lidumil Všehomír]

Mám už otestovaného birda, měnit nechci a na zkoušení nemám nyní ani dostatečný časový fond.

[wike]

Ak ide vyslovene o rychlost routingu, tak by bolo vhodne prehodnotit migraciu na IPv6. Podla dostupnych informacii bol IPv6 zjednoduseny pre rychlejsie spracovavanie na routeroch. Nemozem to posudit z realnej skusenosti, ale prave tieto vlastnosti by mohli pomoct zvysit pps.

[Lidumil Všehomír]

Je nutno routovat IPv4 i IPv6.

[slafly]

Muzu jenom dotaz? Proc takoveto reseni, proc ne treba juniper EX3200 s 10G OEM moduly? Umi stejne veci (vykon/soft) jako cisco ale je levnejsi a IMO i vykonejsi nez zvolene reseni.

[Lidumil Všehomír]

Není EX3200 náhodou switch? Co se týče výkonu doporučoval bych přečíst tuto prezentaci http://wenku.baidu.com/view/cfdad666f5335a8102d220f0.html

Tam zvládli 10Mpps, a co se týče ceny, je řešení s linuxem několikanásobně levnější.

[lertimir]

Doporučil bych oprášit angličtinu a začit si dopisovat s pane Bouerem z uváděné prezentace. Protože mě připadá, že tady půjde o jemné dolaďování parametrů, které zná jen ten, kdo podobný problém řešil.

[Ruža Becelin]

Jenom pro pripad, ze by to zmizelo: tady je PDF verze...

[MMMMMMMMM]

Problém vyřešen ... týkalo se to affinity, ačkoliv jsem měl fronty rozhozené na jednotlivá jádra, tak se to chovalo jako bych to měl na jednom. Nikdy ... NIKDY!!! ... nespouštějte pktgen v subshellu midnight commanderu ... vše mi narval do jednoho vlákna. Tuhle zdánlivou blbost jsem řešil 14 dní. ufff ... howgh :)

[kyytaM]

:) Keby bola potom aj nejaka prezentacia dosiahnutych nameranych vysledkov, bol by som velmi vdacny (a nebol by som asi sam).

[Lidumil Všehomír]

Předběžně mohu říct že bidir mi to jede 2,2Mpps každým směrem a unidir 4,7Mpps při 64B paketech. Jinak je to schopno generovat až 12Mpps ... žádné speciální úpravy, jen nastavení affinity

[Grunt]

Ah, můj člověk. Samozřejmě, že se dá zvýšit propustnost všelijakými babskými radami, ale doporučuje úplně čerstvé jádro, protože nedávno do něj bylo přidáno tohle. Profilování cesty paketů od vytvoření přerušení NICem až po příjem do jádra k zpracování. Věřím že i na trasování cesty paketu uvnitř jádra bude něco existovat (když už nic tak by se v nejhorším případě dalo využít i obyčejné profilování). No a pak samozřejmě vyházet nepotřebné instrukce (někdy to jde až v rozsahu celých procedur, záleží kolik bordelu v ovladačích je) nebo nahrazení náročných méně náročnými. Už to bude asi vyžadovat jistý jaderný skill, ale jde to. Jinak také otevřít třeba Luka a přečíst si co všechno síťové API asi tak zhruba obnáší. Někdy se dají udělat docela razantní změny (jen tak z hlavy mě napadne třeba nahrazení veškerých přerušení pollingem a určitě se bude dát vyštelovat i velikost balíků, které se posílají po sběrnici). Keep tuned.