always load aesni or load it when cpu supports it

[Andre Oppermann]

On 20.10.2013 18:16, John-Mark Gurney wrote:
> Mark Murray wrote this message on Sun, Oct 20, 2013 at 11:38 +0100:
>>
>> On 20 Oct 2013, at 08:00, John-Mark Gurney <jmg at funkthat.com> wrote:
>>
>>> Comments?  Suggestions or ideas?
>>
>> I'd love to have this - /dev/random would be a lot more efficient.
>
> Though we don't have a common interface for this...  This was one of
> the issues I raised w/ the PEFS patch that was brought up recently...
>
> If you want to use the OpenCrypto kernel frame work, then things will
> work...  If you need a lower overhead interface, then you'll have to
> do a lot of wrapping of the code, or copy it, which is worse...

I don't think copying is necessary, even though it was done at times.
The base crypto and hash algorithms are almost all under sys/crypto/
now and used by various other parts including OpenCrypto.  OpenCrypto
then wraps it with a work-queue style API to allow software and dedicated
hardware implementations to work seamlessly.

> The other question now to ask, should we make AES a first class kernel
> interface and bypass the OpenCrypto framework?  Or complete the work
> pjd did to make the OpenCrypto framework more effecient?

The problem at least in some places is the deferred processing nature
inherent to OpenCrypto.  For example in TCP-AO it would be a huge pain
to send the work off and have it call back later when done at some
random point in the future.  Here I need in-line processing to completion
and having AES-NI available there would certainly be helpful instead of
doing it in pure software.

> It does look like we already have a good number of consumers for
> crypto/rijndael: geom_bde, ipsec, random and wlan_ccmp...  Which
> also means that they aren't making use of AES accelerator cards...

Exactly.  Sometimes the deferred processing model as in OpenCrypto is
the right one, sometimes doing it in-place is better.  None of these
cases should be artificially restricted.

-- 
Andre