NetBSD /dev/crypto supports the deflate transform used for SSL compression. If I were to provide patches modifying OpenSSL's compression support to use an engine if available, would they be accepted?
I do not have an open-source driver I can offer which actually hooks this up to a compression engine, but it can be tested with the software implementation in the NetBSD kernel. There are at least three hardware accellerators that do deflate/gzip: Indra Networks, Comtech AHA, and the onboard accellerator on Network Logic XLS and XLP processors. Another will be available very soon from a major vendor I can't identify. This issue also highlights a longstanding limitation of the ENGINE interface I am frankly at a loss as to how to correct. ENGINE wants to submit one transform at a time to the underlying accellerator. This basically maximizes transaction overhead and often makes the accellerator useless for small requests. Most accelerators can do "fused" operations in one pass -- encrypt, MAC, and in some cases even compress. Even for those which cannot, the /dev/crypto interface can compose the necessary sequence of operations and return it to userspace in one round-trip to the kernel, saving most of the overhead of using the ENGINE. I think ENGINE needs some rototilling to be able to accomodate this but I'm not even sure where to start. Implementing compression in ENGINE may make this problem more obvious. -- Thor Lancelot Simon [email protected] "All of my opinions are consistent, but I cannot present them all at once." -Jean-Jacques Rousseau, On The Social Contract ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
