From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ydix4lToyNe for ; Mon, 25 Mar 2013 20:22:43 +0100 (CET) Received: from infra.in.zekjur.net (infra.in.zekjur.net [IPv6:2001:4d88:100e:1::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 25 Mar 2013 20:22:43 +0100 (CET) From: Michael Stapelberg In-Reply-To: <513CA157.3000009@gmail.com> References: <20130122054223.GA25850@tansi.org> <50FE3EAF.3070206@gmail.com> <50FEB647.8060005@gmail.com> <51066847.90305@gmail.com> <20130305125304.3a8e37d5@midna.rag.lan> <513CA157.3000009@gmail.com> Date: Mon, 25 Mar 2013 20:22:41 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dm-crypt] Encrypting with larger packet size (+some experimental patch) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Milan Broz Cc: dm-crypt@saout.de Hi Milan, Milan Broz writes: > So 2 * performance increase? I would expect even more... > (Maybe compare it with new cryptsetup benchmark - in fact it uses much > larger block and it should measure almost real throughput or crypto > engine.) In cryptsetup benchmark I am seeing much higher numbers, but I never get close to that in =E2=80=9Creal=E2=80=9D tests: # Tests are approximate using memory only (no storage IO). PBKDF2-sha1 44887 iterations per second PBKDF2-sha256 34492 iterations per second PBKDF2-sha512 8904 iterations per second PBKDF2-ripemd160 43115 iterations per second PBKDF2-whirlpool 6884 iterations per second # Algorithm | Key | Encryption | Decryption aes-cbc 128b 254.0 MiB/s 264.0 MiB/s serpent-cbc 128b 17.5 MiB/s 17.8 MiB/s twofish-cbc 128b 20.4 MiB/s 20.6 MiB/s aes-cbc 256b 245.0 MiB/s 242.0 MiB/s serpent-cbc 256b 17.5 MiB/s 18.0 MiB/s twofish-cbc 256b 20.4 MiB/s 20.8 MiB/s aes-xts 256b 21.6 MiB/s 21.8 MiB/s serpent-xts 256b 18.0 MiB/s 18.0 MiB/s twofish-xts 256b 21.0 MiB/s 20.6 MiB/s aes-xts 512b 17.0 MiB/s 17.1 MiB/s serpent-xts 512b 18.0 MiB/s 18.0 MiB/s twofish-xts 512b 21.0 MiB/s 20.6 MiB/s > This looks like crash in different layer, IMHO this should happen even > with other devices (try dm-linear). If it is reproducible, perhaps > report it to LKML. How would I be able to reproduce this with dm-linear? As far as I can tell, it doesn=E2=80=99t have a block size parameter? Apparently, using a block size bigger than PAGESIZE is not possible with Linux currently. Ted Ts'o writes that he is surprised to see the patchset to allow that being used in the wild: https://lkml.org/lkml/2012/3/21/493 I have compared dm-linear with the dm-crypt null cipher: echo "0 5856626815 linear /dev/sda2 0" | dmsetup create identity dd if=3D/dev/zero of=3D/dev/mapper/identity bs=3D1M count=3D768 oflag=3Ddir= ect conv=3Dfsync 768+0 records in 768+0 records out 805306368 bytes (805 MB) copied, 4.69666 s, 171 MB/s cryptsetup luksFormat -c null /dev/sda2 cryptsetup luksOpen /dev/sda2 sda2_crypt dd if=3D/dev/zero of=3D/dev/mapper/sda2_crypt bs=3D1M count=3D768 oflag=3Dd= irect conv=3Dfsync 768+0 records in 768+0 records out 805306368 bytes (805 MB) copied, 9.39298 s, 85.7 MB/s This is quite a difference and I wonder what might cause it. Here is the same test with 4096 bytes big blocks: echo "0 5856624640 crypt cipher_null-ecb - 0 /dev/sda2 0 2 block_size 4096"= | dmsetup create sda2_crypt dd if=3D/dev/zero of=3D/dev/mapper/sda2_crypt bs=3D1M count=3D768 oflag=3Dd= irect conv=3Dfsync 768+0 records in 768+0 records out 805306368 bytes (805 MB) copied, 6.25626 s, 129 MB/s So, any ideas on how to further debug where the problem is, or how we can get to approximately 170 MB/s? :-) --=20 Best regards, Michael