From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gilad Ben-Yossef Subject: Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Date: Mon, 6 Mar 2017 16:38:00 +0200 Message-ID: References: <1486463731-6224-1-git-send-email-binoy.jayan@linaro.org> <68f70534-a309-46ba-a84d-8acc1e6620e5@gmail.com> <2aef6e54-805f-e09b-ae66-c198f8c05335@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Binoy Jayan , Rajendra , Herbert Xu , Oded , Mike Snitzer , Linux kernel mailing list , Ondrej Mosnacek , linux-raid@vger.kernel.org, dm-devel@redhat.com, Mark Brown , Arnd Bergmann , linux-crypto@vger.kernel.org, Shaohua Li , "David S. Miller" , Alasdair Kergon , Ofir To: Milan Broz Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com List-Id: linux-crypto.vger.kernel.org On Wed, Mar 1, 2017 at 5:38 PM, Milan Broz wrote: > > On 03/01/2017 02:04 PM, Milan Broz wrote: >> On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote: >> ... >> >>> I can certainly understand if you don't wont to take the patch until >>> we have results with >>> dm-crypt itself but the difference between 8 separate invocation of >>> the engine for 512 >>> bytes of XTS and a single invocation for 4KB are pretty big. >> >> Yes, I know it. But the same can be achieved if we just implement >> 4k sector encryption in dmcrypt. It is incompatible with LUKS1 >> (but next LUKS version will support it) but I think this is not >> a problem for now. >> >> If the underlying device supports atomic write of 4k sectors, then >> there should not be a problem. >> >> This is one of the speed-up I would like to compare with the IV approach, >> because everyone should benefit from 4k sectors in the end. >> And no crypto API changes are needed here. >> >> (I have an old patch for this, so I will try to revive it.) > > If anyone interested, simple experimental patch for larger sector size > (up to the page size) for dmcrypt is in this branch: > > http://git.kernel.org/cgit/linux/kernel/git/mbroz/linux.git/log/?h=dm-crypt-4k-sector > > It would be nice to check what performance gain could be provided > by this simple approach. I gave it a spin on a x86_64 with 8 CPUs with AES-NI using cryptd and on Arm using CryptoCell hardware accelerator. There was no difference in performance between 512 and 4096 bytes cluster size on the x86_64 (800 MB loop file system) There was an improvement in latency of 3.2% between 512 and 4096 bytes cluster size on the Arm. I expect the performance benefits for this test for Binoy's patch to be the same. In both cases the very naive test was a simple dd with block size of 4096 bytes or the raw block device. I do not know what effect having a bigger cluster size would have on have on other more complex file system operations. Is there any specific benchmark worth testing with? Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru