Jivin Ronen Shitrit lays it down ... > Hi > > I'm using the latest version of OCF with SW crypto (no HW acceleration), > I build the OpenSSL package and patch it with the OCF patch: > Why in the OCF ssl patch, the place for running multi threads in > apps/speed.c is changed?? "if(multi && do_multi(multi)) .... " > I see that with this change, even if I choose the multi flag there is no > actual fork done by the speed.c?? > When I move it back, I see that fork is called but the Openssl gets > stuck?!?!
This code was moved down a little. The problem was, speed.c was measuring process start times and all kinds of other things as it was benchmarking the crypto, so the results did not always make sense. It's still not perfect, but at least the startup/initilisation of the crypto threads is mostly out of the way now. I will send you a copy of speed.c seperately to ensure you have it patches appropriately. > I also run: > openssl speed -evp des3 -engine cryptodev -elapsed > openssl speed -evp des3 -elapsed > And got the following results: > when the block to be encrypted is very small (16 bytes) then the regular > Crypto without the OCF is 10 times better, > While when the block is 8k then its only 10% better, > As I understand this is as a result of the transformation from user to > kernel space when using the /dev/cryptodev > and the copying of the buffers from user to kernel space each time. Any > other suggestions?? Thats pretty much it, you are adding a lot of overhead to a 16byte crypto operation if you copy it to the kernel, process it and return it. > Is it possible that we will skip the copy to kernel, and use direct > mode?? As Evgeniy pointed out, yes, it should be possible to get a zero copy implementation (depending on host arch and crypto HW combinations etc). Cheers, Davidm -- David McCullough, [EMAIL PROTECTED], Custom Embedded Solutions + Security Ph:+61 734352815 Fx:+61 738913630 http://www.uCdot.org http://www.cyberguard.com - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
