Re: [RFC 1/3] cryptoapi: AES with AltiVec support

[Sebastian Siewior <bigeasy@linux.vnet.ibm.com>]

Benjamin Herrenschmidt wrote:
>> ==================================================================
>> --- ps3-linux.orig/crypto/Makefile
>> +++ ps3-linux/crypto/Makefile
>> @@ -48,3 +48,7 @@ obj-$(CONFIG_CRYPTO_MICHAEL_MIC) += mich
>>  obj-$(CONFIG_CRYPTO_CRC32C) += crc32c.o
>>  
>>  obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o
>> +
>> +CFLAGS_aes-altivec.o += -O3  -maltivec -mcpu=cell
>> +aes_altivec-objs := aes-alti.o aes-altivec.o
>> +obj-$(CONFIG_CRYPTO_AES_ALTIVEC) += aes_altivec.o
> 
> Ideally (and I know the RAID6 code isnt doing it), the
> code that contains enable_kernel_altivec/disable_kernel_altivec should
> -not- itself be compiled with -malitvec. You don't want the compiler to
> "inadvertently" generate altivec instructions outside of those calls (in
> the function prolog for example).
Yes. aes-altivec.o contains the -maltivec flag and is the only module 
using AltiVec. aes-alti.o uses enable_kernel_altivec & 
disable_kernel_altivec and calls then the AltiVec module.
The raid6 code compiles the raid[1,2,4,8].c files with -maltivec flag 
and uses the noinline keyword in the function that uses AltiVec.
Should I prefer the latter or were you confused with with the - _ in the 
filename and you recommend renaming them?

> I noticed quite a bit of memcpy's around too... see if you can limit
> usage of these.
I check if I can be be sure that the data is always properly aligned

> 
> Ben.
> 

Sebastian