On Wed, Mar 25, 2015 at 10:54 PM, Arno Wagner <arno@xxxxxxxxxxx> wrote: > On Wed, Mar 25, 2015 at 21:51:42 CET, Milan Broz wrote: >> 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 > [...] >> (Why it is so slow for 512bytes sectors? Isn't it problem of hw? >> The overhead should not be such high...) > > I am wondering that too. This hardware may have a really, > really slow key-setup, far slower than the crypto merits. > Would not be the first time that non-crypto people messed > something like this up by faulty assumptions on how things > are used. I'm not sure. I just assumed it was all the overhead of request queue management, servicing interrupts, spinlocks, in addition to the hardware setup time. Doing 512byte sectors results in 80000+ interrupts/sec. Anyways, I wasn't fighting for inclusion of this patch, just providing it in case anyone else is looking at Talitos' performance. I will take a look at the changes in v4.0 kernel and hopefully adapt this patch to the changes. Thanks for your comments, mh -- Martin Hicks P.Eng. | mort@xxxxxxxx Bork Consulting Inc. | +1 (613) 266-2296 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
