Jivin Thor Lancelot Simon lays it down ... > On Thu, Jul 02, 2009 at 12:28:36AM +0200, David McCullough via RT wrote: > > > > The reason the option exists is that in all but the most unusual cases, > > using cryptodev hashing via some HW device is not worth it by any measure. > > There are some people using it, but they have specific applications/needs. > > This is an API limitation -- or was -- within OpenSSL. The way hashes are > fed to the ENGINE effectively cuts performance in half because almost all > accellerators can do HMAC in one pass for the hshes they support. But > there were not, at least a year or so ago, separate EVPs for HMAC. > > I have noticed that those EVPs exist now. That would make hashing in the > ENGINE a lot more efficient. > > More generally, the approach taken by the original authors of the > cryptodev engine to enabling/disabling functionality according to its > performance was the wrong one. The engine *already* has a protracted > startup process in which it tries every algorithm to see which work; > it could very easily do a quick-and-dirty calibration of the crossover > point, in terms of request size, for where hardware vs. software > handling of a request will be quicker.
Yes, but the cross over is not that easy really. If your requirement is straight speed alone, yes, easy, but if CPU utilisation and/or parallelisation come into play, then it gets trickier. Having some HW doing crypto, albiet slower than the CPU can still be beneficial if there is significant "other" processing you can get done while waiting for the crypto HW to return. But yes, for the simple cases it can be automatically determined. Do you know if NetBSD has done anything to fix the 8K request failures I see on some OCF HW drivers (from memory hifn and safenet, but it's been a while so I may be wrong on one of them). Add to that cryptodevs 64K request limit which is also not handled by openssl. > The other things to remember with regard to cryptodev, particularly on > embedded platforms, sare: > > 1) If you have a single, single-core CPU, it can do _one_ operation at > a time at the speed you'll measure with openssl speed -elapsed. But > the bottleneck going out to an accellerator via /dev/crypto is really > a *syscall latency* bottleneck, which can be overcome with parallelism; > for hashes, and even for small encryption requests, a test with, say, > -multi 64 (which is a lot more realistic for most applications), will > reveal that doing most things in hardware is a win. Agreed, but if the overheads of the copyin/copyout to kernel space exceed the cost of just doing the hash, you are better off avoiding /dev/crypto. The usual trend we see is small packets don't cost in that well and larger ones do. Mostly due to the context switching/copying overheads becoming insignificant as the size increases. > 2) The original cryptodev engine suffered from a serious misunderstanding > of the /dev/crypto API, probably because the documentation was unclear. > It basically does twice as many ioctls per session as it has to. We > fixed this in NetBSD but I don't think the change made it back to upstream > OpenSSL. Anything that halves the ioctls is a good thing from my point of view :-) > 3) There are backwards-compatible changes to the /dev/crypto API itself > available (checked into NetBSD quite some time ago, shipped in NetBSD 5) > which were designed to make it much more efficient for realistic use > cases including OpenSSL. Specifically, they streamline the session > creation process, allow asynchronous operation via select/poll/kqueue, > and allow multiple results to be retrieved with a single operation. We > intended to write a new OpenSSL engine to service multiple threads > within an application using a single engine worker thread but that part > isn't done yet. Anyway, the basic support for this is there for the > taking. Supposedly, FreeBSD will pick it up when someone gets the > time. How is/was the helper thread being used ? I sort of figured the kernel/user seperations of /dev/crypto avoided and real need for threads to help out in user space, but that may be my wishfull thinking on my part. Cheers, Davidm -- David McCullough, [email protected], Ph:+61 734352815 McAfee - SnapGear http://www.snapgear.com http://www.uCdot.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
