> 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