helenos-nicf team mailing list archive

[Jirka Michalec <michy@xxxxxxxxxx>]

Ahoj,

> co si myslite o tom, ze bychom uvolnovani paketu ve funkci 
> nic_send_message_impl nechali na funkci write_packet?
>
> data->write_packet(data, packet);
> log_debug("Packet %d sent.", pid);
> -pq_release_remote(data->net_phone, pid);
> packet = next;
>
> Ja totiz paket nechci uvonit hned, ale az za nakou dobu, az si ho 
> precte sitovka.
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.

> Pro vraceni paketu by slo udelat nejakou obalovaci funkci, aby porad 
> driver nemusel nic vedet o phonech.
Takova funkce uz tam je: nic_driver_release_packet

> Muzu si samozrejme napsat vlastni funkci misto nic_send_message_impl, 
> ale prijde mi to pitome, kdyz by se lisila jen v jednom radku.
>
> Druha moznost reseni je podminit to podle navratu write_packet:
>
> log_debug("Sending packet %d.", pid);
> -data->write_packet(data, packet);
> +int rc = data->write_packet(data, packet);
> log_debug("Packet %d sent.", pid);
> +if (rc == E_RELEASE_PACKET) {
> +    pq_release_remote(data->net_phone, pid);
> +}
> -pq_release_remote(data->net_phone, pid);
> packet = next;
Kdyz uz, tak IMO naopak - packet bude uvolnen, nebude-li receno jinak. 
Ale prilis
se mi to nezamlouva - v podstate to dost znecitelni, ze funkce dopadla 
spravne (misto EOK
tam bude nejaky divny kod).


Michy