> If you want this in the mainstream code, you'll need to detect the
> capability at runtime and use your alternate code paths only if the
> hardware is present.

He did. It wouldn't work on Win64, but on Unix detection would actually

> There are advantages in this being present all the time/dynamically enabled
> if it can be done, most users/OS vendors wouldn't bother to configure an
> engine backend anyway.
> I'll disagree with Andy on that aspect only. The engine modules aren't
> particularly useful for this situation where the function is inherent in
> some subset of CPU's, the engines will only get used by a few end users
> that can be bothered to configure them.

As mentioned, in order to fully utilize the pipelined architecture one
would have to implement a number of mode-specific subroutines, most
notably Nx-interleaved and non-interleaved for short input and tail
processing, and wrap them in specific C logic. Putting this all this in
general purpose code serves no purpose. Of course one could argue that
improvement by patching single block function would be impressive
enough, ~4x(?), but why stop there if you can reach for ~20x? This is my
main argument for engine.

> I doubt the OS vendors would bother
> to enable an engine by default, testing of the possible configurations is
> expensive and the costs of support calls if they mess up makes
> autodetecting the engine to use a very unattractive proposition.

One can discuss loading selected engines by default, i.e. you'd have to
work to not load it:-) Then it wouldn't be any different, yet provide
proper isolation for specific pipeline-enabling logic, would it? Either
way, there were more points:-) A.
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to