DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Stapelberg <michael+dmcrypt@stapelberg.de>
To: Milan Broz <gmazyland@gmail.com>, dm-crypt@saout.de
Subject: Re: [dm-crypt] Encrypting with larger packet size (+some experimental patch)
Date: Tue, 5 Mar 2013 12:53:04 +0100	[thread overview]
Message-ID: <20130305125304.3a8e37d5@midna.rag.lan> (raw)
In-Reply-To: <51066847.90305@gmail.com>

Hi Milan,

On Mon, 28 Jan 2013 13:00:07 +0100
gmazyland at gmail.com (Milan Broz) wrote:
> I need some real reason before submitting such patch.
I am running a qnap TS-119P II NAS with Debian GNU/Linux. The device
has a CESA crypto engine, which is supported by the in-mainline-kernel
mv_cesa module. Unfortunately, this crypto engine exhibits the same
symptoms as the one the author of this thread was describing:

With small block sizes, the crypto engine is really slow.

I have done a series of tests with a WD WD3000FYYZ SATA hard disk drive
that achieves a raw read/write rate of about 177 MiB/s:

dd if=/dev/sda2 of=/dev/null bs=1M count=4096 iflag=direct
4294967296 bytes (4.3 GB) copied, 24.2781 s, 177 MB/s

dd if=/dev/zero of=/dev/sda2 bs=1M count=768 oflag=direct
805306368 bytes (805 MB) copied, 4.5337 s, 178 MB/s

Using mv_cesa with aes-cbc-essiv:sha256 (one of the accelerated
ciphers, as cryptsetup benchmark confirms), I get a rate of about 12.9
MiB/s:

dd if=/dev/zero of=/dev/sda2_crypt bs=1M count=4096 oflag=direct
4294967296 bytes (4.3 GB) copied, 332.425 s, 12.9 MB/s

There is a patch by Phil Sutter which makes mv_cesa use the TDMA engine
of that SoC, and it improves performance quite a bit:

dd if=/dev/zero of=/dev/mapper/sda2_crypt bs=1M count=1024 oflag=direct
1073741824 bytes (1.1 GB) copied, 50.5507 s, 21.2 MB/s

This is just to let you know where I am coming from :).

> That said... here is the patch which can use larger block size
> option. It is not complete (mainly IV generators need changes and I
> am afraid there should be morech changes than basic io hints) but it
> should work for basic performance testing if you want to play with it
> (you have to use dmsetup).
> 
> So show your crypto performance numbers now :-)
Thanks for posting this patch. I have set up my device as follows:

echo "0 5858578432 crypt aes-cbc-essiv:sha256
0123456789abcdef0123456789abcdef 0 /dev/sda2 0 2 block_size 4096" |
dmsetup create sda2_crypt

The encryption rate improves significantly:

dd if=/dev/zero of=/dev/mapper/sda2_crypt bs=1M count=1024 oflag=direct
1073741824 bytes (1.1 GB) copied, 26.4864 s, 40.5 MB/s

I hope you realize that this is a real-world usecase for me — I cannot
switch to a full-blown Intel system with AES-NI due to space and power
efficiency reasons. Nevertheless, I need to encrypt my hard disk(s).

I would appreciate it very much if you could implement the FIXME and
commit that patch to dmcrypt.

BTW, when using a block_size of more than 4096 (e.g. 8192),
I get a kernel oops:

[   36.601704] device-mapper: ioctl: 4.23.1-ioctl (2012-12-18) initialised: dm-devel@redhat.com
[   36.658525] bio: create slab <bio-1> at 1
[   36.672332] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[   36.680496] pgd = decf8000
[   36.683212] [00000000] *pgd=1eeed831, *pte=00000000, *ppte=00000000
[   36.689537] Internal error: Oops: 17 [#1] ARM
[   36.693911] Modules linked in: sha256_generic dm_crypt dm_mod nfsd auth_rpcgss nfs_acl nfs lockd dns_resolver fscache sunrpc hmac sha1_generic ehci_hcd mv_cesa mv643xx_eth usbcore inet_lro libphy usb_common mv_dma evdev loop gpio_keys autofs4 ext4 jbd2 mbcache sd_mod crc_t10dif sata_mv libata scsi_mod
[   36.720988] CPU: 0    Not tainted  (3.8-trunk-kirkwood #1 Debian 3.8-1~experimental.2)
[   36.728940] PC is at create_empty_buffers+0x24/0x11c
[   36.733921] LR is at create_empty_buffers+0x14/0x11c
[   36.738899] pc : [<c00f44ec>]    lr : [<c00f44dc>]    psr: 80000013
[   36.738899] sp : de8e5d10  ip : c04eb02c  fp : c093d280
[   36.750416] r10: 00100100  r9 : df6370b8  r8 : c093d280
[   36.755658] r7 : dea39c80  r6 : 00000000  r5 : 00000000  r4 : c093d280
[   36.762206] r3 : 00000000  r2 : 00000001  r1 : 00002000  r0 : 00000000
[   36.768756] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   36.775914] Control: 0005397f  Table: 1ecf8000  DAC: 00000015
[   36.781678] Process blkid (pid: 931, stack limit = 0xde8e41b8)
[   36.787530] Stack: (0xde8e5d10 to 0xde8e6000)
[   36.796608] 5d00:                                     c093d280 df63717c 00000000 c00f4ad8
[   36.806338] 5d20: 00000001 c00f4b14 c0502024 00000040 00000000 c055af38 00000010 000213d0
[   36.816046] 5d40: 00000000 c0501a24 df637180 c00f9850 c093d280 df63717c 00000000 2ba657f0
[   36.825732] 5d60: 000000d0 00200200 00100100 c0092b4c 60000013 00000001 df63717c 00000000
[   36.833978] 5d80: dea39c80 c093d280 00200200 00100100 de8e5da0 c009b434 2ba657ff 2ba657f0
[   36.844821] 5da0: de8e5da0 de8e5da0 91827364 de8e5dac de8e5dac de8e5db4 de8e5db4 00000000
[   36.853045] 5dc0: c057bee0 00000000 00000001 2ba657f0 00000001 df63717c 000001ff dea39c80
[   36.863832] 5de0: 00000000 c009b6c4 00000000 dea39c80 2ba657f0 00000000 00000001 00000000
[   36.873483] 5e00: 00000000 2ba657f0 df63717c dea39c80 ffffffff c0093d08 00000001 00000000
[   36.883145] 5e20: dea39c80 de8e5ec0 00000101 de8e5f00 657f0000 000002ba 00000fff b6f03000
[   36.892789] 5e40: 000005b7 de8e5eb8 def41520 def6a1d8 decfadb8 00000028 00000000 de8e5ef8
[   36.902532] 5e60: df6370b8 dea39cc0 2ba657f1 00000001 b6f031f0 00000000 00000000 00000040
[   36.912233] 5e80: 0096ca78 00000000 c00f99e4 de8e5ec0 fffffdee de8e5f80 00000040 dea39c80
[   36.921889] 5ea0: de8e4000 de8e5ec0 00000000 c00cd8b0 657f0000 000002ba 0096ca78 00000040
[   36.931551] 5ec0: 00000000 00000000 00000000 00000001 ffffffff dea39c80 00000000 00000000
[   36.941233] 5ee0: 00000000 00000000 dee603c0 00000000 00000000 00000000 657f0000 000002ba
[   36.950920] 5f00: 00000000 00000000 00000040 00000000 00000040 00000000 00000000 00000000
[   36.960574] 5f20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   36.970268] 5f40: 0096ca78 dea39c80 0096ca78 de8e5f80 00000000 00000040 00000040 c00cdfb4
[   36.979934] 5f60: dea39c80 0096ca78 657f0000 000002ba dea39c80 00000000 0096ca78 c00ce0c4
[   36.989635] 5f80: 657f0000 000002ba 00000040 0096ca70 00000040 0096c018 00000003 c000e508
[   36.999297] 5fa0: 00000000 c000e380 0096ca70 00000040 00000003 0096ca78 00000040 00008000
[   37.008957] 5fc0: 0096ca70 00000040 0096c018 00000003 657f0000 b6fc7000 0096ca58 00000000
[   37.018632] 5fe0: 0096c064 bee91370 b6fac760 b6f0320c 60000010 00000003 00000000 00000000
[   37.026882] [<c00f44ec>] (create_empty_buffers+0x24/0x11c) from [<c00f4ad8>] (create_page_buffers+0x34/0x4c)
[   37.036764] [<c00f4ad8>] (create_page_buffers+0x34/0x4c) from [<c00f4b14>] (block_read_full_page+0x24/0x358)
[   37.046646] [<c00f4b14>] (block_read_full_page+0x24/0x358) from [<c009b434>] (__do_page_cache_readahead+0x194/0x1ec)
[   37.057230] [<c009b434>] (__do_page_cache_readahead+0x194/0x1ec) from [<c009b6c4>] (force_page_cache_readahead+0x6c/0xa4)
[   37.068240] [<c009b6c4>] (force_page_cache_readahead+0x6c/0xa4) from [<c0093d08>] (generic_file_aio_read+0x290/0x6dc)
[   37.078906] [<c0093d08>] (generic_file_aio_read+0x290/0x6dc) from [<c00cd8b0>] (do_sync_read+0x90/0xcc)
[   37.088348] [<c00cd8b0>] (do_sync_read+0x90/0xcc) from [<c00cdfb4>] (vfs_read+0xa4/0x17c)
[   37.096569] [<c00cdfb4>] (vfs_read+0xa4/0x17c) from [<c00ce0c4>] (sys_read+0x38/0x64)
[   37.104447] [<c00ce0c4>] (sys_read+0x38/0x64) from [<c000e380>] (ret_fast_syscall+0x0/0x2c)
[   37.112924] Code: e1a05000 e1a03000 ea000000 e1a03001 (e5932000) 
[   37.119055] ---[ end trace c844ca55a4ae58f6 ]---


-- 
Best regards,
Michael

  reply	other threads:[~2013-03-05 11:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-22  4:18 [dm-crypt] Encrypting with larger packet size Dinesh Garg
2013-01-22  5:42 ` Arno Wagner
2013-01-22  6:04   ` Dinesh Garg
2013-01-22  7:24     ` Milan Broz
2013-01-22  8:00       ` Dinesh Garg
2013-01-22 15:54         ` Milan Broz
2013-01-24 19:44           ` Dinesh Garg
2013-01-25 23:25             ` Arno Wagner
2013-01-28 12:00             ` [dm-crypt] Encrypting with larger packet size (+some experimental patch) Milan Broz
2013-03-05 11:53               ` Michael Stapelberg [this message]
2013-03-10 15:05                 ` Milan Broz
2013-03-25 19:22                   ` Michael Stapelberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130305125304.3a8e37d5@midna.rag.lan \
    --to=michael+dmcrypt@stapelberg.de \
    --cc=dm-crypt@saout.de \
    --cc=gmazyland@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox