Re: VIA Padlock: +30% XTS Performance by using ECB

[Andre Bubel <news@andre-bubel.de>]

On 23.04.2010 17:44, Mario 'BitKoenig' Holbe wrote:
> Hello,

Hi Mario,

> the VIA Padlock engine comes without native XTS-AES support, thus
> compared to CBC-AES or ECB-AES XTS-AES performs quite bad on VIA CPUs
> because it calls the Padlock ACE for each single AESenc() operation.
> Using the Padlock's ECB-AES saves calls to the Padlock ACE and improves
> the XTS-AES performance by 30% and more even in a naive proof-of-concept
> implementation.
> The idea comes from DiskCryptor which does this since v0.9.583.106.

The same problem exists with the mv_cesa driver. I really like to have a 
solution for this as the performance of the system is mainly cripled by 
the hard disk encryption.

> I have no idea where this should finally be implemented, since it slows
> down XTS on non-accelerated CPUs. Maybe a seperate xts-aes-padlock
> driver would make sense depending on how specific this is to VIA
> Padlock, i.e. how it performs on other non-XTS-capable accelerators.

I'm currently trying to get an understanding of the kernel crypto code, 
but my impression is that instead of breaking support with the 
synchronous API the better way would be to introduce asynchronous 
ciphers (e.g. acipher) that can be used transparently by crypto_template 
implementations to form an ablkcipher. In that way all crypto modes 
would be supported and accelerated through hardware, even if it doesn't 
provide an in-hardware implementation.

As I mentioned I'm new to the kernel API, so what is the opinion of 
experienced developers on this? Is that in reach of the current API 
architecture?

> Please CC: me in replies, I'm not a member of the list. Mail-F'up2
> should be set correctly.

Best regards,
André Bubel