[dm-crypt] AES-XTS performance

[Igor Novgorodov]

> On 11/15/2010 01:36 PM, Igor Novgorodov wrote:
>> Hello!
>> I've   got   a   question   regarding   encryption   performance  with
>> XTS mode  in  dm-crypt,  which is too low for what i
>> get.
>> 
>> Test system:
>> - Supermicro X8DTH-6F
>> - 1 x 4-Core Xeon E5620 with HyperThreading & AES-NI
>> - 12Gb RAM DDR3 Reg ECC
>> 
>> Preparation:
>> # mount -t tmpfs tmpfs -o size=4G /mnt/tmpfs
>> # dd if=/dev/zero of=/mnt/tmpfs/image
>> # losetup /dev/loop0 /mnt/tmpfs/image

> Loop is not ideal device to test but it is not the problem.

> The main problem is that dm-crypt uses only one core per device.

> If you want to do some tests, try this patch
> http://lkml.org/lkml/2010/11/12/344

> (but there is still some issues and it will not help much
> if only one process generates IOs.)

Yes, i know about synchronous nature of dm-crypt,
but i thought that using AES-NI somehow alleviates
this problem, as it as i remember uses asynchronous crypto api (AEAD?),
but i may be wrong, just read somewhere.

Thanks, i'll try your patch and will report of any problems found.

>> And with CBC mode we get reasonable read performance (for AES-NI), but
>> writing is as almost slow as before:

> I think the write slowdown is partially loop problem here.
Yes, it looks so, as AES is quite symmetrical on
encryption/decryption. Tests on real filesystem shows same enc/dec
speed.

>> What is the problem here?
>> With aes-cbc-plain64 i get ~560Mb read, and another slow write ~110Mb.

> Nice to benchmarking, but do not use plain/plain64 in CBC mode for data.
> (It is vulnerable.)

Of course, i've read about watermarking attacks.
If XTS mode will remain too slow, i'll switch to CBC-ESSIV.

>> Any suggestions? Why write speed is so low?

> Can you please try patch above? Will it help here?
> (There are more possible fixes but stability is the No.1 here,
> and we have still some unresolved problems with that.)

>> And why with XTS i get 50% speed drop, is that normal?

> In principle, XTS run 2x AES operation in comparison to CBC mode,
> so I would say it is expected.

Hmm. It looks correct.

>> In Windows with Trucrypt internal benchmark i get 1.6Gb/s
>> AES encryption speed with AES-NI even on low-end Core i5-620.

> You cannot compare internal benchmark to dm-crypt over loop.
> dm-crypt uses 512b sectors and mainly block layer limits it here.
Accoding to http://www.truecrypt.org/docs/?s=modes-of-operation
truecrypt uses 512b unit size too, but, of course, raw in-memory
encryption is not compared to multiple-layer model of linux, but i
thought that difference of hunderds of percents is too big.
But it may be due to a multithreaded nature of TC.

> If you use device-mapper zero target as backing device you can get
> better numbers but still it is comparing something different.

I'll try that, thanks, i didn't even thought of this target before :)

> Milan