There are some fairly severe performance hits in engine support unless the engine includes all the submodes as well.
That includes things you are just starting to play with now, like the combined AES+SHA1 on x86.
For features that are part of CPU's - rather than plug in cards - my preference would be that the implementation is inline so that every last drop of performance can eventually be wrung out of it.
With card drivers, the internal call stack in OpenSSL is generally noise compared with the driver stack and card I/O overhead so there's no significant gain in inlining, plus the potential pain of cards/drivers changing under you makes inlining a net lose anyway.
Of course, that's only an opinion, and it's up to you to decide what to implement.
Pete
That includes things you are just starting to play with now, like the combined AES+SHA1 on x86.
For features that are part of CPU's - rather than plug in cards - my preference would be that the implementation is inline so that every last drop of performance can eventually be wrung out of it.
With card drivers, the internal call stack in OpenSSL is generally noise compared with the driver stack and card I/O overhead so there's no significant gain in inlining, plus the potential pain of cards/drivers changing under you makes inlining a net lose anyway.
Of course, that's only an opinion, and it's up to you to decide what to implement.
Pete
To: [email protected]
From: "Andy Polyakov via RT" <[email protected]>
Sent by: [email protected]
Date: 11/05/2011 09:44PM
Cc: [email protected]
Subject: Re: [openssl.org #2627] SPARC T4 support for OpenSSL
> As some of you may be aware the new Oracle SPARC T4 processor has
> hardware crypto support just like its predecessors SPARC T1,T2,T3.
>
> However unlike the prior SPARC T series processors the hardware crypto
> is not hyper-privileged but is instead new instructions accessible from
> unprivileged userland code. Basically a very similar model to what is
> available in Intel processors with AES-NI,
Cool! Or should I say "finally"? :-)
BTW, https://blogs.oracle.com/BestPerf/entry/20110928_sparc_t4_openssl
says that 3.46GHz Westmere delivers 660MBps on AES-256-CBC benchmark.
Given the result we are talking about encrypt. I wonder about decrypt.
Westmere delivers 3x on CBC decrypt [Sandy Bridge more than 5x] and
question is how does it, a parallelizable mode, look on T4?
> but it is much more than just
> AES. The hardware supports instructions for:
> AES, DES, Camellia
> MD5, SHA1, SHA256, SHA512
> MONTMUL, MPUL
Is there publicly available documentation? If not, is there non-publicly
available documentation and under which terms?
> We currently have an new "t4" engine implemented that provides support
> for AES,MD5,SHA1,SHA256/384/512 using the hardware instructions on the
> SPARC T4 processor.
>
> We implemented this as a new engine because at the time we made the
> choices this is how Intel AES-NI support was done in OpenSSL CVS head.
> We have noticed that the Intel AES-NI support has changed and it is now
> directly integrated rather than being an engine.
>
> We would like to contribute patches for SPARC T4 support to OpenSSL with
> the intention of them being part of the core release.
>
> We can contribute the engine as we currently have it if that is of
> interest. However we would like to know if the OpenSSL community
> believes that SPARC T4 should be done similar to Intel AES-NI instead
> and integrated "inline" into the main implementation.
I can't speak for whole community, but I'd argue that "inline"
implementation can become of interest only if it targets FIPS. Otherwise
engine is just as appropriate, especially if it's patch-free engine in
http://www.openssl.org/contrib/intel-accel-1.4.tar.gz style. This would
allow for easier and faster adoption (that's what matters, right?). As
for possibility of integrating it in the core release. By taking code
into core we also implicitly undertake its maintenance. And the latter
is problematic, because we don't have access to appropriate hardware or
documentation. Question if somebody [like Oracle] wants to do something
about it is implied.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
