On Mon, Aug 20, 2007 at 12:08:19PM +0200, Sebastian Siewior wrote:

* Andi Kleen | 2007-08-20 12:47:14 [+0200]:

quoted

quoted

Not modprobe, but the crypto subsystem. If you have the generic C code
and the assembly variant it picks the assembly over C. The selection is

But only if they're both loaded. Who loads both? 

In my case I do.

You're unusual then.

I'm thinking of standard distribution kernel users though. They 
just want to tell some high level configuration they want aes
(or twofish) and expect the most efficient implementation 
to be loaded automatically.

The distribution kernel could just disable the generic AES,
but if that's a good idea there this could as well be done in all
kernels.

quoted

quoted

In that case yes. Would it help to add MODULE_ALIAS("aes") to the
assembly version in order to load it (atleast both)?

No, modprobe will only load the first it finds.

The s390 guys have MODULE_ALIAS("aes"); in their hw driver [1]. If it
doesn't load both (aes.ko + aes_s390.ko) modules, than I wonder what's
the reason for this.

When only one is enabled then aes_s390 will be loaded. 

But when both are enabled only one wins. At least on my system
that seems to be the C version.

quoted

quoted

quoted

Also if one implementation is always better than the other
then I see little reason to ever have both.

If you are sure that nobody needs aes on machnies prio i586 than you
could disable the generic version on i386.

Why should the i586 version not run on 486/386? 

I assumed it uses some opcodes which are not available on 486. 

There are not many. From a quick scan I didn't find any.

I assume the 586 refers to it being tuned for P5? Although that would
be also weird, few people still care about P5 tuning and it's quite
different from newer CPUs and likely not beneficial on them.

quoted

quoted

BUT: you might get into some trouble if you remove it from selections
because some modules select it automaticly, IEEE80211_CRYPT_CCMP for
instance.

Ok that is a problem.

Not really I guess. The aes algorithm shouldn't be directly used by the
wlan stack. It should only make sure that the user does not forget to
enable aes since it is required for CCMP. 

Well it still would need to be solved to get rid of the generic
aes/twofish. I don't know how unfortunately. Or could the select
just be dropped?

-Andi