Hi
I got your code, I did the patch correctly.
If you look into the code you will see that only if SIGALRM is not
defined then we will get to the do_multi
Where you put it, in my code SIGALRM is defined, so I never get there.
So I move it a little below see ssl.patch attached, I think it should be
fix in the OCF release.
Now I still get hang when multi is bigger then 2, I can see that part of
the threads didn't finish?!
Any suggestions??
Ronen Shitrit Marvell Semiconductor Israel Ltd -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David McCullough Sent: Wednesday, November 02, 2005 1:37 AM To: Ronen Shitrit Cc: [EMAIL PROTECTED]; linux-crypto@vger.kernel.org Subject: Re: OpenSSL with OCF 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 _______________________________________________ Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi List archive: http://lists.logix.cz/pipermail/cryptoapi
speed.patch
Description: speed.patch
