lkml.org 
[lkml]   [2012]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] crypto: serpent - add x86_64/avx assembler implementation
On Wed, May 30, 2012 at 05:39:49PM +0200, Andi Kleen wrote:
> > I agree with that. Currently when I boot my PC with a new 3.4 kernel all the
> > ciphers from the intel-aesni module get loaded whether I need them or not. As
> > Jussi stated most people using distros probably won't need the
> > serpent-avx-x86_64 module get loaded automatically, so it's probably better to
> > leave it that way.
>
> That means you got a 50% chance to use the wrong serpent.

You should always get the best one available. For example, when
you request for "aes" all implementations of it will be loaded by
modprobe.

> This was a continuous problem with AESNI and the accelerated CRC,
> that is why the cpuid probing was implemented.

The only case where it doesn't work is if you have some variants
built-in and the faster ones built as modules. But then the answer
is to either build all of them as modules or all of them built-in
so that priority-based selection can work.

Can you provide an example where it doesn't work as intended?

What we could do is to use the cpuid-based probing when an algorithm
is needed to selectively load the relevant implementations instead
of all of them. However, for most algorithms it won't make that
big a difference since all the available ones will be loaded anyway.

Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


\
 
 \ /
  Last update: 2012-05-31 00:01    [W:0.416 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site