| Thread Previous • Date Previous • Date Next • Thread Next |
On 22.4.2011 0:11, Jirka Michalec wrote:
Máš pravdu, špatně jsem vyjádřil, co je tou prioritou. Tou je mít maximálně rychlé předávání packetů - a možná beru mylný předpoklad (pocházející z monolitických kernelů), že kopírovat tu paměť je příliš drahá operace. Pro správné uvážení by to chtělo mít nějaké odhady performance IPC. Ovšem nějaké bottleneckovitosti packet serveru/DMA bych se zase tak nebál, pokud by se ukázalo, že to něco brzdí, tak se alokace a uvolňování packetu v nějakých cache-frontách dají implementovat lock-free.Stejně jako Zdeněk si myslím, že nekopírovat packety je priorita číslo 1 a té se musí podřídit vše. I když by to vyžadovalo existenci packet serveru nebo nějaké jiné hraní si s právy na alokaci DMA, prostě kopírovat se nesmí, pokud to karta umožňuje (což E1000 dělá, u RTL to musíš nakopírovat do toho vnitřního bufferu stejně, že?).Technicky vzato nemusim - mohu prenastavovat adresu bufferu pro odeslani na fyzickou adresu dat packetu.Optimalizovat by se mělo pro typický případ - nejspíše ten, že packet je z největšího rozsahu, který většina karet podporuje, což je 32bitový rozsah. Není to tak velké omezení a karty, které zvládají 64bitový rozsah, prostě tu featuru nevyužijí. Karta tak vždy ověří, že packet je v rozsahu, který podporuje a pokud vyžaduje menší rozsah, tak holt musí přealokovat packet a kopírovat nebo si to nějak přizpůsobit. Pokud by tohle měl být velký problém, tak se může do systému doimplementovat nastavení říkající, z jakého rozsahu se mají packety alokovat (ale to už je záležitost net stacku a ne nás).Priorita cislo jedna to teoreticky byt muze, ale pri pritomnosti packet serveru bude komunikace s nim uzkym hrdlem systemu - cili misto zdrzeni pri kopirovani dat dojde u packetu ke zdrzeni kvuli IPC, cekani na zamky v packet serveru. A jelikoz se alokace packetu deje nezavisi na zarizeni, pres ktere packet odejde (to ani nemuze byt znamo), bude dochazet ke kolizim i s packety jdoucimi napr. do lo rozhrani, ktere vlastne vubec zadnou DMA nepotrebuji. Ano, cekani na zamky se nepujde zbavit ani pokud aplikace vyuzije DMA primo kvuli zamykani v dma_allocate (nehlede na dalsi zdrzeni az bude DMA server => IPC). A ted je otazkou: je rychlejsi kopirovani 1.5kB dat (v prumeru zrejme mene, me ve statistikach sitovky na notebooku vychazi prumer cca 150B/packet) nez poslani IPC zpravy (=> 2x context switch) + alokace DMA pameti + kolize se vsemi novymi packety v systemu? Pri mereni (linux, gcc, prumer ze 100 000 000 kopirovani, HelenOS implementace) mi vyslo kopirovani 1522B casove ekvivalentni 4040 instrukcim s -O0, 845 s -O3 a (pro srovnani) 485 v linuxove implementaci (resp. nejspis memcpy zabudovana v gcc), u 150B to je 470 (-O0), 130 (-O3) a 130 (linux). To mi (zejmena ta verze s -O3) prijde prijatelne, pokud se jinde v network stacku nic kopirovat nebude. Mimochodem, pamet alokovatelna pro DMA muze byt omezenym zdrojem tudiz alokace packetu skrz DMA na strane aplikace se zvysuje pravdepodobnost neuspechu pri teto alokaci, zvlast, kdyz se tak budou alokovat i packety, pro ktere to neni potreba.Osobne myslim, ze pristup "toto je priorita cislo 1 a vse se tomu musi podridit" neni nejlepsi. Chce si to rozmyslet, jaka je cena okolo a jak to bude rychlejsi. Ostatne pristup "priorita cislo jedna" take obcas vede k ne zrovna peknym resenim.
Tohle je asi otázka na Honzu, jestli v tom není nějaký zádrhel. Tedy pro přijímané packety by driver požadoval od DMA nějakou paměť a pro odesílané by si (v případě potřeby) zjistil její adresu. Nicméně aplikační úroveň (resp. knihovna) by o tom, že tato paměť je nějak zvláštní a musí se uvolňovat skrze DMA stejně musela vědět, ne? Nebo jak zjistí DMA, že ji může znovu přidělit?Jeste mne napada jeden mozny pristup: mit volani zajistujici, ze nejaka pamet se stane pristupna pro DMA - obdoba linuxoveho dma_map_single/dma_unmap_signgle, v soucasnosti (jeden packet v jedne strance) spise obdoba dma_map_page/dma_unmap_page, ta pro DMA nastavi jednu stranku. V podstate by slo jen o zjisteni fyzicke adresy a zajisteni, aby po celou dobu pouzivani pameti k DMA prenosu nedoslo k jeji zmene (pri absenci swapovani to znamena znemoznit jeji uvolneni - neni to nahodou rovnou zajisteno nasdilenim stranky?). Takoveto reseni ma vyhodu v tom, ze aplikace alokujici packet o DMA vubec vedet nemusi (=> nemusi mit zadna zvlastni prava) a vse si zajisti driver sam, ale neresi to problem u zarizeni pracujici jen v 32bit adresach na 64bit stroji (ten by resilo jen nastaveni "pamet pro packety alokovat pouze v dolnich 32 bitech"). Jak je to vlastne s e1000? Ta zvlada 64bit adresy ci nikoliv?
Pořadí "současné" komunikace je stejně nedefinované - sessions zajistí to, že se komplikovanější komunikace sestávající se z více IPC zpráv nebudou prolínat.Dobrá, klidně se jej na to můžeme zeptat. Napíšeš mu, nebo mám já?To je jedno, klidne mu napisi, pokud chces.Hmm, v tom případě bych zauvažoval o tom uvolňování podle návratové hodnoty, protože se mi z hlediska uživatele vůbec nelíbí mít dvě funkce na uvolňování packetu, které se mají použít podle kontextu a v jednom případě způsobí deadlock a ve druhém ještě hůře nějaké nedefinované chování.Ano, to je asi rozumnejsi. Sam bych se priklanel k variante, aby si driver musel vynutit neuvolneni (cili "packet se uvolni, nerekne-li driver opak"). Prijde mi to i cistci v tom, ze takova navratova hodnota bude jinou variantou uspechu, pripadne chybove kody (ukaze-li se, ze se v nejakem pripade bude hodit rici "packet jsem nemohl odeslat") budou pouzitelne s automatickym uvolnenim packetu.I když je tu ještě jedna alternativa - nezamykat vůbec pro uvolňování packetu a místo toho jenom vytvořit session, ve které se ta zpráva odešle (čili bez synchronizačních problémů). Popravdě jsem se zatím async sessions vyhýbal, ale asi bych je do komunikace měl zanést - tím pádem by se nemuselo zamykat jenom kvůli posílání nějakých zpráv (ono se vlastně nemusí zamykat ani teď, protože poslání jedné zprávy je atomické, ale "uzamykat resource" pro komunikaci mi přišlo jako dobrý nápad).Nemuze u async sessions dochazet k problemum s prohazenim poradi akci ruznych vlaken stejneho device? Resp. v NICF me nenapada me nic, kde by predbehnuti zpravy jineho vlakna mohlo vadit, ale spis jestli jsem neco v tomto smeru neprehledl... Jinak to zni jako dobre reseni - v driverech bude o nebezpeci deadlocku mene.
Radim
| Thread Previous • Date Previous • Date Next • Thread Next |
