Re: [dm-crypt] Larger encryption requests from dm-crypt

[Milan Broz <gmazyland@gmail.com>]

On 03/25/2015 09:01 PM, Martin Hicks wrote:
> 
> Hi,
> 
> I figured that I'd push this patch to the list for comments.  This stems
> from recent work on the linux-crypto/linuxppc-dev lists regarding
> AES-XTS support for the Freescale Talitos engine.  The background can be
> found in this message and the rest of the thread:
> 
> http://marc.info/?l=linux-crypto-vger&m=142533320730893&w=2
> 
> The AES-XTS mode in Talitos allows sending a starting IV (usually sector
> #), and the hardware increments this as new sectors are
> encrypted/decrypted.  This allowed me to investigate not only
> dispatching 4kB IOs, but also to extend the scatter/gather lists to
> include as much IO as Talitos can handle in a single request (64kB - 1,
> or rounding down, 60kB).
> 
> The original performance numbers that I quoted follow, with the extra
> larger-IO up to 60kB line:
> 
> 			Write (MB/s)	Read (MB/s)
> Unencrypted		140		176
> aes-xts-plain64 4kB	113		115
> aes-xts-plain64 512b	71		56
> aes-xts-plain64 60kB	120		132
> 
> with IOs up to 60kB, the performance is even closer to the un-encrypted
> values.
> 
> It's certainly not a pretty patch, but as a proof of concept it does
> work.  I avoided the IV issues by just ifdeffing them out...

Hi,

Well, I already commented it on that thread.
http://marc.info/?l=linuxppc-embedded&m=142530788521032&w=2

TBH I do not share optimism here because we can use different dmcrypt IVs,
not only consecutive one. (It is discussed in this thread as well.)

Note that dmcrypt should always be generic without any specific hw-related tweaks.

It is very interesting for testing your hardware but I am afraid it is not usable
in upstream kernel this way.

Also please note that there are very complex changes in dmcrypt in kernel 4.0,
not sure if you will be able to easily port it there...) but you should definitely
compare performance with the 4.0 version.

(Why it is so slow for 512bytes sectors? Isn't it problem of hw?
The overhead should not be such high...)

Thanks,
Milan

p.s.
The real list for DM patches is dm-devel@redhat.com with optional cc here
if it is dmcrypt related (on dm-devel are more experts familiar even with dmcrypt).