On Mon, 2005-08-15 at 12:14 +0200, Attila Nagy wrote:
Balazs Scheidler wrote:
A fenti probléma enyhíthető lenne kicsit, ha a kripto műveleteket külön thread/processz végezné, nem? Ebben az esetben gyakorlatilag Nem vegeztunk, pedig erdekes lenne. Jobban vegig gondolva nem hiszem, hogy jobb megoldas out-of-line vegezni a kripto muveleteket a masodik processzoron, ez mindenkeppen latency-t ad hozza. Inkabb arra kell figyelni, hogy az emlitett kripto kodok lehetoleg lockolas nelkul fussanak. Ezt kifejtenéd kicsit? Hogyhogy lockolás nélkül? Ha jól sejtem, jelenleg minden openssl-t használó része a Zorpnak külön forkolt processzben fut és nem többszálú. Hol jön itt képbe a lockolás?
A Zorp tobbszalu, nem hasznal fork()-t. Szoval sejtesem szerint meg mindig erdemesebb inline hasznalni a kripto muveletet, ha azokat nem vedi lock, akkor valoszinuleg viszonylag jol fog skalazodni, es nem keletkezik latency. (ld. lentebb)
Latency... Gyanítom, hogy a memóriasávszélesség (legrosszabb esetben) azért nagyobb, mint a legnagyobb PCI buszé. :)
Ez igaz, de azert meg mindig meg kell varnod azt, hogy a masik processzoron elinduljon az adott muvelet, azaz felebredjen az ott futo szal.
Arról nem is beszélve, hogy a kernel egy processzt futásidőben is áttehet másik processzorra és mivel a kripto nincs szétválasztva mondjuk a protokollelemzéstől, így viszonylag rossz ötletnek tűnik az erre forkolt processzt processzorhoz kötni.
De lehet, hogy teljesen hülyeség, ehhez tényleg meg kellene nézni valami életszerű környezetben.
Szerintem is merni kell ehhez, de en inkabb arra fogadnek, hogy az inline futo kripto jobb lesz (nagy mennyisegu szal eseten O(1)-es utemezovel) -- Bazsi