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.) > 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. > 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.) > 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. > 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. If you use device-mapper zero target as backing device you can get better numbers but still it is comparing something different. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
