helenos-nicf team mailing list archive

[Radim Vansa <radim.vansa@xxxxxxxxx>]

On 20.4.2011 10:35, Jirka Michalec wrote:
> On 04/20/2011 09:08 AM, Radim Vansa wrote:
> > > Ale ona si aplikace prece rekne o paket a knihovna, ktere se pta uz 
> > > zaruci aby byl nalokovan pouzitalne i pro driver... i baz packet 
> > > serveru.
> > > Pokud jde o 32bitovou kartu v 64bitovem systemu, tak ta knihovna 
> > > muze zarucit (misto paket serveru) alokaci nize v dolnich 32 bitech. 
> > > Nebo to muze driver kopirovat, jen pokud zjisti, ze adresa je vetsi.
> > > Nemuset vubec kopirovat pakety je dulezite u velkych prenosovych 
> > > rychlosti.
> > Souhlas.
> To sice ano,  ale otazkou je, budou-li mit vsechny aplikace 
> pouzivajici networking stack
> take opravneni pouzivat DMA. On tu je i obecny problem - jak knihovna 
> alokujici packet
> zjisti, jakou konkretni pamet ma pro packet pouzit (mysleno z hlediska 
> flagu u dma_allocate)?
> To muze byt trochu problem i ted - alokuje packet server pamet v 
> nizsich 32bitovych adresach
> nebo mlcky predpoklada, ze si s tim pripadne karta na amd64 s >4GB 
> pameti poradi?
> (nehlede na to, ze pripadne ISA karty s podporou DMA by byla potreba 
> alokace v jeste
> nizsich adresach, na coz by obecna alokace packetu tez mela byt 
> pripravena).
> Ve vysledku si ta knihovna, bude-li vyuzivat DMA, bude muset zjistit, 
> jaka omezeni
> na fyzicke adresy karty v systemu vyzaduji, a z nich vybrat to nejvice 
> omezujici (nebot
> pri alokaci neni znamo, kterou kartou se packet posle...).
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?).
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).
> > > Mozna bychom se o tomhle mohli vice pobavit i s Deckym!
> > Nevím, tohle se mi zdá zbytečné a stejně to nejspíše nechá na nás.
> Ja si naopak myslim, ze zrovna to, jestli v budoucnu bude mozne 
> pocitat s tim, ze packety
> budou na strane aplikace alokovany pomoci DMA frameworku, je na 
> Deckeho dobra otazka
> a nikdo jiny nam plany budouciho networking stacku nebude moci odhalit.
Dobrá, klidně se jej na to můžeme zeptat. Napíšeš mu, nebo mám já?
> S tim, ze bychom se na jeho budouci vyvoj nemeli vubec ohlizet, zas 
> tak uplne nesouhlasim
> - zmeni-li se networking stack, bude treba NICF upravovat, pokud uz se 
> smerem budoucich
> zmen budeme pocitat, nebudou pripadne upravy tak narocne. Pokud budou 
> ovladace psany
> s tim, ze packet je pristupny pro DMA prenos, a packet pristupny byt 
> prestane, budou se
> muset ovladace prepsat (a jelikoz se pouziti pameti pro DMA, ktera tak 
> nebyla alokovana,
> se nemusi vzdy projevit nebo se projevi divnym zpusobem, zapomenuty 
> puvodni kod v nejakem
> driveru by mohl zpusobit dost zvlastni chovani...)
Ano, já bych taky uvažoval trochu více do budoucnosti.
> > > > Takova funkce uz tam je: nic_driver_release_packet
> > > Aha, nak jsem ji prehledl...
> > > Tak jak je tedka implementovana, tak ale pouzit nejde, ten zamek je 
> > > zamcen pro cteni a nic_driver_release_packet() by ho zamykala pro 
> > > zapis.
> > > Zacinam si rikat, jestli nebude lepsi, kdyz si prece jen udelam 
> > > vlastni send_message().
> > Pokud je packet uvolňován v send message, tak se to dělo bez téhle 
> > funkce. Pokud je uvolňován v handleru interruptu, tak žádný zámek 
> > zamknut není, čili můžeš ji použít. Pravda, že ve write_packet použít 
> > nejde - tak si říkám, že je tam tím pádem ještě bug, protože pro 
> > posílání zprávy NETu by se měl main_lock zamykat pro zápis. Napadá 
> > vás někoho, jak transparentně zjistit, jestli se to volá nepřímo ze 
> > send message (teda bez zkoumání stacku), nebo jí musíme předávat 
> > nějaký extra argument, což není tak elegantní?
> Krom zkoumani stacku ci predavani extra argumentu zadny jiny rozumny 
> zpusob neni, kazdopadne funkce chovajici se ruzne jen podle volajici 
> funkce neni dobry napad. To uz radeji od ni udelat dve ruzne se 
> jmenujici varianty (s tim, ze ta jedna by jen zamkla zamek a zavolala 
> druhou).
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í.
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).

Radim
> _______________________________________________
> Mailing list: https://launchpad.net/~helenos-nicf
> Post to     : helenos-nicf@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~helenos-nicf
> More help   : https://help.launchpad.net/ListHelp