helenos-nicf team mailing list archive

[Jirka Michalec <michy@xxxxxxxxxx>]

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...).


> > 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.

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...)

> > > 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).