Jivin Ronen Shitrit lays it down ... > 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.
Great, thanks, I can't believe I hadn't seen the multi thing, but there you go :-) I added you patch to my tree so it's included in the next ocf-linux release, Thanks, Davidm > -----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]; linux-crypto@vger.kernel.org > 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]; 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 -- 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
