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

Martin Hicks mort at bork.org
Fri Mar 27 14:40:28 CET 2015


On Wed, Mar 25, 2015 at 10:54 PM, Arno Wagner <arno at wagner.name> 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 at bork.org
Bork Consulting Inc.     |   +1 (613) 266-2296


More information about the dm-crypt mailing list