helenos-nicf team mailing list archive

[Zdenek Bouska <zdenek.bouska@xxxxxxxxx>]

> Myslim, ze to neni uplne dobry napad, a to proto, ze - jestli jsem
> pochopil Deckeho spravne - v budoucim
> networking stacku nebudou packety alokovany pomoci DMA frameworku
> (myslim, ze konkretne rikal, ze
> o existenci DMA ma vedet jen driver a ne aplikace alokujici packety; ze
> v konecne fazi nebude
> packet server rikal urcite). Tudiz se stejne nebude nikdo moci
> spolehnout, ze muze primo adresu, na ktere jsou data
> packetu ulozena, predat karte (adresa se nemusi vejit do registru,
> jde-li o 32 bit kartu v 64 bit systemu, jestli bude
> zarucena spojitost packetu si nejsem jist - ale bude-li zacinat na
> zacatku stranky, tak zarucena bude)
> a driver bude muset chte nechte data kopirovat do svych internich bufferu.

Na budouci networking stack bych se moc neohlizel, kdovi jestli bude.

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.

Mozna bychom se o tomhle mohli vice pobavit i s Deckym!

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