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. 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. 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. 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. Thor ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
