> 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
