On Mon, 2009-09-14 at 23:13 +0200, David Woodhouse via RT wrote:
> For now, let's at least address the major disadvantage of the engine,
> which is that it doesn't even get _used_ unless someone registers it.
Updated patch, following the discussion in PR#2305:
On Tue, 2010-07-20 at 00:59 +0200, S
On 26/03/2010 18:31, Andy Polyakov wrote:
> 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...
Hum ? Maybe the openssl team doesn't have th
On Fri, 2010-03-26 at 18:31 +0100, Andy Polyakov wrote:
> > 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
PM,
> Though I am not a member of the OpenSSL team, I totally agree with you.
> As for the AES, the Westmere CPUs have also a new instruction for the
> GHASH (pclmulqdq / _mm_clmulepi64_si128).
It's not an instruction *for* GHASH, it's an instruction that among
other thing can be used for GHASH
> 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 'opens
On Thu, 2010-03-25 at 17:57 +0100, PMHager wrote:
>
> As all major compilers for Intel CPUs support intrinsics and, if used
> correctly, optimize to the same instructions as direct assembler, IMHO
> these policies should be reconsidered to keep OpenSSL competitive.
>
> For good reasons perlasm
Though I am not a member of the OpenSSL team, I totally agree with you.
As for the AES, the Westmere CPUs have also a new instruction for the
GHASH (pclmulqdq / _mm_clmulepi64_si128). This as well is only available
as intrinsic or in native assembler.
So, when I offered some weeks ago a contri
On Mon, 2009-09-14 at 23:13 +0200, David Woodhouse via RT wrote:
> I'm a little confused about the way Intel AES-NI is supported in OpenSSL
> HEAD.
>
> This is just a feature of new CPUs, like SSE is. Yet SSE support is
> directly included in the normal assembly routines for x86, while AES-NI
> is
I'm a little confused about the way Intel AES-NI is supported in OpenSSL
HEAD.
This is just a feature of new CPUs, like SSE is. Yet SSE support is
directly included in the normal assembly routines for x86, while AES-NI
is implemented separately as an engine. Why is that?
Are we slowly moving _all
