Hi OK, found the problem, see new patch for speed.c. The problem was that for EVP we first call to print_messege which set an alarm (which should signal to the encryption to stop), then we init the session and after it we start encryption. Since the machine I'm using is _very_ "lazy" then the init session might take a while (specially when Other encryption tasks are exploring the CPU) and we miss the alarm signal for part of the threads. So I change the sequence: first init the session then call print_messege (set an alarm), And only then start the encryption.
This patch completely solve the hang issue, and I can see that when using multi-thread (more then 6) with buffer bigger then 512 bytes the OCF gets better performance then with the openssl crypto. Regards Ronen Shitrit Marvell Semiconductor Israel Ltd -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ronen Shitrit Sent: Wednesday, November 02, 2005 4:42 PM To: David McCullough Cc: [EMAIL PROTECTED]; [email protected] Subject: RE: OpenSSL with OCF 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]; [email protected] 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.patch2
Description: speed.patch2
