> My question was about the inconsistency between, for example, > SSE-optimised and AESNI-optimised functions. Both are implemented as > perlasm; that's not relevant. What _is_ relevant, however, is that the > SSE optimisations end up in the 'core' AES_encrypt() function which is > tested by 'openssl speed aes', while the AESNI version is in an engine > and isn't even used by default unless the application explicitly asks > for it. > > My patch (unapplied for 6 months now) would at least fix the problem of > the AESNI engine not being used automatically,
The reason for low priority is that the code is in development, lack of hardware... > but I still don't quite > understand why it should be an engine while SSE support is not. I'd like > to understand the logic. The original reason for suggesting the engine was alignment requirement for key schedule imposed by submitter [from Intel]. The requirement couldn't (and can't) be tolerated in common code. Another reason for favoring engine is option to implement algorithms that otherwise wouldn't make sense to implement. Simplest example in this particular case is ECB. It's no point implementing dedicated ECB subroutine in general code (won't be any faster), while dedicated ECB subroutine for specifically AESNI delivers 3x performance improvement (over non-dedicated procedure using single block AESNI subroutine). Another such example is [Galois] counter mode (which is under development). > Should we be moving the SSE optimisations out into their own engine too? It's an option... If there was an inter-procedural or "super-procedural" (something similar to above mentioned ECB) optimization specific for SSE it would definitely be the case. But as of now, SSE code is limited to lowest-level leaf functions and lifting it into an engine is problematic to motivate. Not to mention that it would result in code duplication (meaning more maintenance as if it wasn't enough). A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
