always load aesni or load it when cpu supports it

[Poul-Henning Kamp]

In message <20131021185308.GA56872 at funkthat.com>, John-Mark Gurney writes:

>> Those APIs should do whatever is fastest, for the request it gets.
>
>Except that it isn't that simple...  AES-NI isn't free in the kernel
>because we have to dump FPU context and do other work that means for
>single block AES, it's probably faster to do pure software than doing
>the FPU work necessary to use AES-NI...

Yes, "its complicated", and my point is that we should isolate that
complication one place, rather than spread it all over the place.

Obviously the API must have an open() where the crypto-consumer
state their intentions, which algo(s), which mode(s), what sizes
etc, to give the central crypto-service useful info for heuristics.

The actual trafic-densisty, if that is going to be a factor, should 
be measured however.

Code is notoriously bad at guessing the intention behind its
activation.

GBDE certainly cannot tell up front if its going to be a busy
filesystem or not.  Needless to say, that may be also be function
of time.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.