* Stefan Hellermann | 2008-03-02 13:04:37 [+0100]: >But I get much lower speed than with aes-cbc-essiv:sha256. Yes, I expected this :) The aes-cbc operation is supported directly in HW. So the driver just says here is the key, source, destination, length and now do it. So the HW fetches the key once and is going to process the whole request (lets say 4 KiB) in one go. The XTS blockmode on the other hand encrypts encrypts only 16 bytes in one go and performs some GF operations in between. This is repeated until we encrypt the whole request. So for a 4 KiB we need here 257 calls to the HW instead of one (the one extra is to encrypt the IV). For every encryption call we have to reset the HW key. According to the spec fetching the key from memory takes more time than the whole encryption process as it (in case of a 16 byte block). This might still be faster than the pure software solution. Anyway, XTS is way more complex than CBC and part of it is done in software what we can't change. >With xts I get 57MB/s while reading the cryptodev with dd, and >90% sys in top, 0% wait >With cbc-essiv I get about 75MB/s while reading it with dd, 60% sys int top, 30% wait >without cryptodev I get 75MB/s while reading the raw lvm-volume with dd, 40% sys, 50% wait >I do a blockdev --flushbufs beetween each read. According to this numbers I would say in CBC mode the HD is breaking in XTS the CPU is. I could try to tune it a little but don't expect much. Could you please compare xts with and without padlock? Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
