• Akcelerace vykonu routeru pomoci nVidia CUDA

Zdravim,

rad bych se zeptal, zda jste nekdo resil a pripadne mate zkusenosti s akceleraci vykonu routeru pomoci technologi CUDA na kartach nVidia.

Vypocetni potencial tam je obrovsky a kdyz tim jsou louskat WEP hesla, proc by pres to nesel prohanet routing, shaping, L7 analysis a dalsi veci ?

Zatim sem nevygoogloval zadny relavantni vysledky k tomu tematu, protoze dotaz typu "nvidia cuda ethernet accelleration" neni asi moc to prave orechove ...

Predem dikas za Vase odpovedi ! 8) :

o 7 dní později

teoreticky by to jiste slo, problem vidim v tom, ze to zrejme znamenalo kompetni prepsani TCP/IP stacku se vsemy nadstavbami typu QoS do CUDA nebo radeji OpenCL, coz asi nebude uplne snadne. Dalsi problem je celkova architektura sitovani v linuxu: provadi to samotny kernel a nevim nevim jestli je realne, aby offloadoval TCP/IP na externim device = GPU.

to by neměl bejt problem po úpravě kernelu ale otázka spíš zní, proč? Máme tu specializovaný procesory pro síťový operace, Specializovaný L3 switche který zvládnou většinou všechno nativně v procesoru s ukrutnou rychlostí. Takže se ptám, Kdo by něco stavěl na nVidia cuda když cuda je maximálně komerční projekt kterej je ještě k tomu ne moc vyladěnej a jako takovej + grafický procesory chcípnou hned jak přestanou nVidii dostatečně vydělávat.

Jako i tak mám o tom maximální pochyby. GPU je stavěný na masivní paralelní operace a síťovej provoz je více méně seriová záležitost pokud nekrmíš 10gigem 8 síťovek. Z tohodle důvodu si myslim že by GPU nebyla až taková výhra a to už vůbec nemluvim o spotřebě nVidiáckých GPU.

No prave mi slo o pripad, kdy chci resit provoz na napriklad sest gigabit optickejch sitovek, tedy vlastne paralelni provoz, kdy mi prijde skoda nevyuzit potencialu grafik ci by to slo mozna i pro L7 analyzu ci DPI (deep packet inspection) ... A spotreba nVidia grafik co maji CUDU nemusi byt tak drsna, protoze to zas neni zpracovani obrazu pro hru, tedy muzeme grafiku nataktovat na mensi vykon a omezit tim spotrebu, ackoliv procak se bude flakat a grafika taky, jen stivoky budou makat az jim kremik nebude stacit :

jako růžově to nevidim. Ano, nvidia má api na cuda, ano, říkaji jak to dokáže něco spočítat ovšem ta grafika neni rychlejší například v komprimaci videa ačkoliv by měla bejt rychlejší. Teď se bavim o smysluplný komprimaci videa v 1080p60 v rozumný kvalitě třeba 10-20Mbit a ne o kompresi videa na ipod a podobně. Podle mě ta grafika nezvládne drsně oprimalizovaný výpočty tak jako CPU. Jo maji to na počítání těch jejich projektů ale to je vymakaný z důvodu komerce a aby měly čim krmit marketingový cáry papíru. Neni to tak dávno co nVidia předváděla marketing založenej na nVidia cuda a možnost přispívat výpočty do nějakých projektů... copak si kupuju grafiku za 5k abych na ní pouštěl nějaký cizí výpočty? Ne, kupuju jí kvůli hernímu výkonu kterym v době tohodle jejich žvatlání moc neoplívaly tak to poslaly do eteru aby se o nich vědělo na čež přeznačily kodová označení jejich grafik aby pozvedly prodejnost... jako nepočítal bych s nVidia cuda na routerech. Kdyby to totiž fungovalo, už by to nějaký cisco nebo juniper používal ve svých routerech.

Pokud routuješ 6 gigových ethernetů, tak to dáš na dnešnim průměrnym PC bych řek. Samozřejmě bez shapingu a firewallu. A možná by se hodilo i 6 jader, každý jádro pro jeden ethernet což v mikrotiku už přiřadit ručně lze. A nebo možná i 6 jader pro 6 ethernetů + 2 jádra na shaping, firewall což je 8 jader. Jako jsou to odhady. Pak totiž už budeš docela dost na stropě paměťových zběrnic který dneska docela začínaji zaostávat.

jako růžově to nevidim. Ano, nvidia má api na cuda, ano, říkaji jak to dokáže něco spočítat ovšem ta grafika neni rychlejší například v komprimaci videa ačkoliv by měla bejt rychlejší. Teď se bavim o smysluplný komprimaci videa v 1080p60 v rozumný kvalitě třeba 10-20Mbit a ne o kompresi videa na ipod a podobně. Podle mě ta grafika nezvládne drsně oprimalizovaný výpočty tak jako CPU. Jo maji to na počítání těch jejich projektů ale to je vymakaný z důvodu komerce a aby měly čim krmit marketingový cáry papíru. Neni to tak dávno co nVidia předváděla marketing založenej na nVidia cuda a možnost přispívat výpočty do nějakých projektů... copak si kupuju grafiku za 5k abych na ní pouštěl nějaký cizí výpočty? Ne, kupuju jí kvůli hernímu výkonu kterym v době tohodle jejich žvatlání moc neoplívaly tak to poslaly do eteru aby se o nich vědělo na čež přeznačily kodová označení jejich grafik aby pozvedly prodejnost... jako nepočítal bych s nVidia cuda na routerech. Kdyby to totiž fungovalo, už by to nějaký cisco nebo juniper používal ve svých routerech.

Pokud routuješ 6 gigových ethernetů, tak to dáš na dnešnim průměrnym PC bych řek. Samozřejmě bez shapingu a firewallu. A možná by se hodilo i 6 jader, každý jádro pro jeden ethernet což v mikrotiku už přiřadit ručně lze. A nebo možná i 6 jader pro 6 ethernetů + 2 jádra na shaping, firewall což je 8 jader. Jako jsou to odhady. Pak totiž už budeš docela dost na stropě paměťových zběrnic který dneska docela začínaji zaostávat.

1) vsechno smeruje k OpenCL

2) GPU jsou brutalne vykone v masivne paralelnich vektorovych vypoctech v plovouci carce a to hlavne v single precision, double je tam radove pomalejsi, idkyz treba FERMI to dosti zlepsila.

3) napr. folding@home je na GPU vykonnejsi radove 20x-30x oproti nejlepsim CPU, ale pouze v nekterych operacich, resp. pouze v GROMACS jadru.

4) on mluvi o deep packet inspection, to dneska zadny CPU na 6x Gb asi vazne nezvladne, zato GPU by to klidne dat mohlo.

5) tak zrovna pametovy sbernice a sbernice obecne dneska uplna brzda nejsou, v memtestu86+ 4.20 muj novy sandy bridge ukazuje propustnost RAM (jen DDR3-1333) neco okolo 17GBps (gigabyte), coz neni zrovna malo a to ma jen dual channel, u viceprocesorovych NUMA sestav se pametova propustnost u NUMA-AWARE aplikaci scita. Pravda je, ze oproti propustnosti L1 cache, ktera ukazuje 110GBps, to brzda je :)

Takovy dual socket s tripple channel dneska umi protahnout RAMkou cca 40-60GBps, coz neni malo.

A takova PCI-E 2.0 umi protlacit slusnou rychlost. nejvetsi brzda byvavala sdilena FSB, ktera uz ale v modernich systemech neni.

Cisco je posledni dobou docela bida, kdy porad resi nejaky "super-mega video" blbosti a sitovej HW a SW moc kupredu nejde ...

Juniper je na tom lepe, ...

To zda to planuji / neplanuji - ci jak to je se zkusim poptat na Cisco Expo '11 :

Radeji koupim jednu ci dve grafiky za ctyrku, nez mit procak se sesti jadry, ktery spis v pripade problemu mam problem vymenit, protoze neni na tak standartni sbernici jako grafika a hlavne jich necni takove mnozstvi (a nejsou za takove prachy).

Co se tyce sbernic, tak PCI-Express 2.0 toho zvladne docela dost, ne ? 8Gigabitu/s jednim smerem ...

BTW: Kdyz sme u tech sbernic ... Na Alixu je dost mrzute, ze (krom 1D) umi max. dve miniPCI karty - myslis, ze by se dalo udelat redukci ci pripojis do miniPCI a do te zapojis treba dalsi dve, ctyry PCI karty ? Mel by to byt podobny princip PCI-Raiser-Card, ne ? :

Co se tyce sbernic, tak PCI-Express 2.0 toho zvladne docela dost, ne ? 8Gigabitu/s jednim smerem ...

Ve skutecnosti to je 8GigaBYTE, tedy cca 64Gigabit :) PCI-E 3.0 bude opet 2x rychlejsi, tedy 16GBps jednim smerem, tedy 128Gbps FD pro jeden x16 slot. PCI-E je interne prepinana (neco jako ethernetovy switch), takze velice dobre skaluje. Nove CPU maji PCI-E integrovane.

1) vsechno smeruje k OpenCL

2) GPU jsou brutalne vykone v masivne paralelnich vektorovych vypoctech v plovouci carce a to hlavne v single precision, double je tam radove pomalejsi, idkyz treba FERMI to dosti zlepsila.

3) napr. folding@home je na GPU vykonnejsi radove 20x-30x oproti nejlepsim CPU, ale pouze v nekterych operacich, resp. pouze v GROMACS jadru.

4) on mluvi o deep packet inspection, to dneska zadny CPU na 6x Gb asi vazne nezvladne, zato GPU by to klidne dat mohlo.

5) tak zrovna pametovy sbernice a sbernice obecne dneska uplna brzda nejsou, v memtestu86+ 4.20 muj novy sandy bridge ukazuje propustnost RAM (jen DDR3-1333) neco okolo 17GBps (gigabyte), coz neni zrovna malo a to ma jen dual channel, u viceprocesorovych NUMA sestav se pametova propustnost u NUMA-AWARE aplikaci scita. Pravda je, ze oproti propustnosti L1 cache, ktera ukazuje 110GBps, to brzda je :)

Takovy dual socket s tripple channel dneska umi protahnout RAMkou cca 40-60GBps, coz neni malo.

A takova PCI-E 2.0 umi protlacit slusnou rychlost. nejvetsi brzda byvavala sdilena FSB, ktera uz ale v modernich systemech neni.

1. kromě microsoftu obzvlášť když od opengl odstoupil i Carmack ale ten bude jistě podmáznutej

2. jo brutálně výkoný na něco co člověk nepotřebuje a v síťovim provozu jde o seriovou komunikaci. Jo fermi, o tom se radši nezmiňovat.

3. to samí, neni to síťovej provoz ale nějaký optimalizovaný instrukce pro výpočty tohoto druhu s malim přísunem externích dat což síťovej provoz rozhodně neni. nVidia se tim proslavila ovšem ta jejich cuda padá na hubu při obyčejný komprimaci videa kde to je navíc exrémně omezený. Tam by měla přece frčet ne? nefrčí.

5. no víš jak to je, syntetický testy si můžou říkat co chtěji a dual channel s propustností 17Gbps je nic. Vem si že tam chceš protahnout 6Gbps dat a seš na 1/3 zátěže ramek + to musí nějak ukočírovat hromadu dalších věcí jako třeba čistě náhodnej read/write přístup malích bloků/paketů a tahat navíc z ramek další info pro routing, nějak to musí koukat taky do firewallu což se bude tahat z ramek každou chvíly znova a znova. Jo 17Gbps při read buffered neni nic vypovídající.

a to vůbec nemluvim o zátěži typu IRQ. Kdo má na bráně PC a MKv5 tak ať se podívá kolik z toho mu vyžíraji IRQčka procesor. U mě to dělá minimálně 50% z aktuálního vytížení CPU. Tahle architektura nikdy nebyla dělaná na záplavu IRQček a vždycky s tim měla problémy.

BTW: Kdyz sme u tech sbernic ... Na Alixu je dost mrzute, ze (krom 1D) umi max. dve miniPCI karty - myslis, ze by se dalo udelat redukci ci pripojis do miniPCI a do te zapojis treba dalsi dve, ctyry PCI karty ? Mel by to byt podobny princip PCI-Raiser-Card, ne ? :

bohužel jsem v datasheetu nenašel nic o IRQ linkách na miniPCI na alixu který by odpověděly na tvou otázku. Vemu ho do ruky a kouknu na piny zběrnice jestli jsou zapojený. Kdyby byly, byla by tu reálná šance že to půjde.

1. kromě microsoftu obzvlášť když od opengl odstoupil i Carmack ale ten bude jistě podmáznutej

2. jo brutálně výkoný na něco co člověk nepotřebuje a v síťovim provozu jde o seriovou komunikaci. Jo fermi, o tom se radši nezmiňovat.

3. to samí, neni to síťovej provoz ale nějaký optimalizovaný instrukce pro výpočty tohoto druhu s malim přísunem externích dat což síťovej provoz rozhodně neni. nVidia se tim proslavila ovšem ta jejich cuda padá na hubu při obyčejný komprimaci videa kde to je navíc exrémně omezený. Tam by měla přece frčet ne? nefrčí.

5. no víš jak to je, syntetický testy si můžou říkat co chtěji a dual channel s propustností 17Gbps je nic. Vem si že tam chceš protahnout 6Gbps dat a seš na 1/3 zátěže ramek + to musí nějak ukočírovat hromadu dalších věcí jako třeba čistě náhodnej read/write přístup malích bloků/paketů a tahat navíc z ramek další info pro routing, nějak to musí koukat taky do firewallu což se bude tahat z ramek každou chvíly znova a znova. Jo 17Gbps při read buffered neni nic vypovídající.

a to vůbec nemluvim o zátěži typu IRQ. Kdo má na bráně PC a MKv5 tak ať se podívá kolik z toho mu vyžíraji IRQčka procesor. U mě to dělá minimálně 50% z aktuálního vytížení CPU. Tahle architektura nikdy nebyla dělaná na záplavu IRQček a vždycky s tim měla problémy.

1) Ehm, tak si pust goole a zadej tam OpenCL, predposledni je skutecne C, nikoli G

2) proc by neslo analyzovat ty packety, co prichazeji z nekolika ifacu, paralelne? Ty fermi mas? predpokladam, zes ji nevidel ani z vlaku. V soucasne dobe je to nejvykonenjsi GPU na trhu a ne nahodou vyuziva NEJVYKONNEJSI POCITAC NA SVETE FERMI GPU :) viz top500.org

3) vsadim se, ze to je mizernou iplementaci, protoze jine ulohy prepsane do CUDA ci OpenCL zvlada bravurne, opet, viz 1. pricka na top500.org

4) vsimej si velikosti pismenek, Gb != GB :)

5) priznam, ze uplne do hloubky architektury PC nevidim, ale mam pocit ze MSI-X to alespon castecne resi.

1) Ehm, tak si pust goole a zadej tam OpenCL, predposledni je skutecne C, nikoli G

2) proc by neslo analyzovat ty packety, co prichazeji z nekolika ifacu, paralelne? Ty fermi mas? predpokladam, zes ji nevidel ani z vlaku. V soucasne dobe je to nejvykonenjsi GPU na trhu a ne nahodou vyuziva NEJVYKONNEJSI POCITAC NA SVETE FERMI GPU :) viz top500.org

3) vsadim se, ze to je mizernou iplementaci, protoze jine ulohy prepsane do CUDA ci OpenCL zvlada bravurne, opet, viz 1. pricka na top500.org

4) vsimej si velikosti pismenek, Gb != GB :)

5) priznam, ze uplne do hloubky architektury PC nevidim, ale mam pocit ze MSI-X to alespon castecne resi.

1. vim co je C a co G. S Carmackem jsem trochu ujel.

2. jak říkám zase jenom teoretický výpočty podle datasheetu k chipu kde se veme největší číslo udávající flops.

3. ano, jiné úlohy, předevšim úlohy projektů typu folding@home

4. o 4 bodu jsem nemluvil ale koukám že jsem se přehlídnul, sorry. Ale zase syntetický testy. To je asi tak vypovídající jako rychlosti zběrnic u grafických karet kde se udává propustnost zkomprimované textury a její následne rozbalení a jeji velikost se počítá jako reálná data co to dokázalo přenýst což je hnus. No a zase se bavíme o čistě číselném výpočtu marketingového oddělení bez úvahy časů pro obsluhu ramek.

5. ano, částečně. Bohužel stačí aby jsi do hraničního routeru osadil aktivní wifi kartu která začne generovat 10x větší IRQ traffic než 1GBit síťovka a celí se to sype k zemi resp. podstatně vzroste zátěž CPU. Vždycky to bude problem. Na network jsou speciální síťový chipy ve specializovaných hardwarech a když potřebuješ routovat 6x1Gbit ethernet, tak si koupíš L3 switch kterej to zmákne.

ale to je jedno, neni v našich silách upravit linuxovej kernel tak, aby používal GPU jako CPU. To by spíš snad šlo opačně tak aby kernel běžel v GPU. Mě tak napadá, co ty ethernety pro hráče kde to má na síťovce nějaký CPU + 256MB ramky + nějakej linux. Jako zdá se mi to blbost ale nějak to fungovat musí.

1) Ehm, tak si pust goole a zadej tam OpenCL, predposledni je skutecne C, nikoli G

2) proc by neslo analyzovat ty packety, co prichazeji z nekolika ifacu, paralelne? Ty fermi mas? predpokladam, zes ji nevidel ani z vlaku. V soucasne dobe je to nejvykonenjsi GPU na trhu a ne nahodou vyuziva NEJVYKONNEJSI POCITAC NA SVETE FERMI GPU :) viz top500.org

3) vsadim se, ze to je mizernou iplementaci, protoze jine ulohy prepsane do CUDA ci OpenCL zvlada bravurne, opet, viz 1. pricka na top500.org

4) vsimej si velikosti pismenek, Gb != GB :)

5) priznam, ze uplne do hloubky architektury PC nevidim, ale mam pocit ze MSI-X to alespon castecne resi.

1. vim co je C a co G. S Carmackem jsem trochu ujel.

2. jak říkám zase jenom teoretický výpočty podle datasheetu k chipu kde se veme největší číslo udávající flops.

3. ano, jiné úlohy, předevšim úlohy projektů typu folding@home

4. o 4 bodu jsem nemluvil ale koukám že jsem se přehlídnul, sorry. Ale zase syntetický testy. To je asi tak vypovídající jako rychlosti zběrnic u grafických karet kde se udává propustnost zkomprimované textury a její následne rozbalení a jeji velikost se počítá jako reálná data co to dokázalo přenýst což je hnus. No a zase se bavíme o čistě číselném výpočtu marketingového oddělení bez úvahy časů pro obsluhu ramek.

5. ano, částečně. Bohužel stačí aby jsi do hraničního routeru osadil aktivní wifi kartu která začne generovat 10x větší IRQ traffic než 1GBit síťovka a celí se to sype k zemi resp. podstatně vzroste zátěž CPU. Vždycky to bude problem. Na network jsou speciální síťový chipy ve specializovaných hardwarech a když potřebuješ routovat 6x1Gbit ethernet, tak si koupíš L3 switch kterej to zmákne.

ale to je jedno, neni v našich silách upravit linuxovej kernel tak, aby používal GPU jako CPU. To by spíš snad šlo opačně tak aby kernel běžel v GPU. Mě tak napadá, co ty ethernety pro hráče kde to má na síťovce nějaký CPU + 256MB ramky + nějakej linux. Jako zdá se mi to blbost ale nějak to fungovat musí.

Tohle je samozrejme cele ciste akademicka debata amateru jako jsme my ;)

GPU urcite neni generic CPU, ale to, ze FERMI based supercomputer je na prvni pricce tom500.org znamena, ze vytvoril rekord v linpacku, coz skutecne neni nejaky teoreticky vypocet ale velice respektovany prumyslovy benchmark. Ato uz neco proste znamena. To neni zadny marketing.

Ale vice mene souhlasim, ze vylozene pro routovaci ucely GPU asi uplne nejvhodnejsi nebude, protoze to skutecne nejsou nejake dokola se opakucii vektorove vypocty nad nejakou mnozinou dat.

Mimochodem, netusis, jak to dopadlo s pocinem CESNETu o PC-based router s nazvem Liberouter?

UPDATE: ted koukam, ze 3 ze 4 nejvykonnejsich superpocitacu na svete jsou postaveny na nVidia FERMI :)

ne to vůbec nevim.

o 4 měsíce později

Zdravim,

dnes jsem se tu nejak zacetl ohledne Siklu a po x hodinach procitani ruznych threadu jsem narazil na tento. Jelikoz

jsou linux routery moje oblibene tema, tak jsem neodolal, registroval se a trochu se zapojim do diskuze ...

Co takhle napsat do googlu "GPU based router" ? => packet shader ...sice jsem nikde nenasel ani zdrojaky, ani binarky,

ale jelikoz nejsem majitelem zadneho GPU, tak jsem asi nemel poradnou motivaci hledat. Nicmene uz jsem cetl o nekolika

projektech.

Totiz - od te doby, co se delaji multi-queue sitovky jiz routing/shaping zas tak seriovy nejni. Zda se mi, ze je

tady prilis velky pocet lidi zaslepen Mikrotikem, namisto aby si dalo praci s "normalnim" linuxem a videlo vice "pod

poklicku". Nedavno jsem resil na shaperu (Xeon E5620) proc mam pretizene jen jedno jadro - reseni je v SMP affinity -

- vetsina kanalu (jednoportove) sitovky byla pridelena jednomu jadru. Takze jsem to rovnomerne rozhazel a byl klid.

Resp. jeste jsem musel pouzit hash tabulky pro TC , ale to uz je trochu offtopic.

Dale jak zde nekdo zminoval prekopani celeho TCPIP stacku kvuli offloadingu - co takhle XORP a externi routing engine ?

liberouter - jako moc pekna sranda, take jsem o to mel velky zajem. Ale to jen do te doby, kdy jsem pred par mesici

zvedl telefon a zavolal do Invea tech (prodejce onoho zeleza) - 4x1 Gbps - 247 000,- Kc , 2x 10 Gbps - 337 000 Kc a

4x 10 Gbps krasnych 538 000 Kc (ano, vidite dobre). Dokazali mi na to rici jen to, ze toho vyrabeji malo a proto je

to tak drahe. Tak jsem se jim vysmal, ze si za to radsi koupim Cisco. Pripadne - NetFPGA je paradni vec,

jen jsem to jeste nekoupil. V porovnani s COMBO-LXT (liberouter project) je NetFPGA za krasnych cca 40 000 Kc a

jsou k tomu vyvijene i ruzne "funkce". Jelikoz je to programovatelne hradlo, tak to muze byt router, traffic generator,

switch, proste temer cokoliv. Strci se to treba do Atomu (PC stejne slouzi jen k preprogramovani hradla) a je z toho

router jak svin. Dodnes si myslim, ze na necem takovem jede Juniper : Jen se nesmi cekat, ze to pojede v Mikrotiku :

Vice na http://www.netfpga.org/

fedy: tak tomu rikam odpoved hodna mistra : diky - jdu zurive goooglit :

Zjevně na NetFPGA někdo vyvíjí i NATku ... ;-)

fedy: tak tomu rikam odpoved hodna mistra : diky - jdu zurive goooglit :

kdybys nahodou narazil , tak to sem posli ... jiste se bude kdekomu hodit. ja osobne k mojim potrebam

v radech stovek mbps to nevyuziju, bohate staci spravne nastaveny quadcore xeon. ale co vim co bude za rok, ze :-)

jo, ted koukam, ze jsem kecal - NetFPGA 4x 1Gbps stoji jen 20kKc ! to je dost dobry ...

📡 Telekomunikace.cz