From mboxrd@z Thu Jan 1 00:00:00 1970 From: Milan Broz Subject: Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency Date: Wed, 13 Jan 2016 08:01:01 +0100 Message-ID: <5695F62D.3050705@gmail.com> References: <20160104201343.GQ16023@sirena.org.uk> <5514385.nEhTK7fEcU@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5514385.nEhTK7fEcU@wuerfel> Sender: linux-kernel-owner@vger.kernel.org To: Arnd Bergmann , Mikulas Patocka Cc: device-mapper development , Mark Brown , Milan Broz , Jens Axboe , keith.busch@intel.com, linux-raid@vger.kernel.org, martin.petersen@oracle.com, Mike Snitzer , Baolin Wang , linux-block@vger.kernel.org, neilb@suse.com, LKML , sagig@mellanox.com, tj@kernel.org, dan.j.williams@intel.com, Kent Overstreet , Alasdair G Kergon List-Id: linux-raid.ids On 01/13/2016 12:38 AM, Arnd Bergmann wrote: > On Tuesday 12 January 2016 18:31:19 Mikulas Patocka wrote: >> >> Another possibility is to use dm-crypt block size 4k and use a filesystem >> with 4k blocksize on it (it will never send requests not aligned on 4k >> boundary, so we could reject such requests with an error). > > Is there ever a reason to use something other than 4K block size on > dm-crypt? Most existing sw FDE systems use 512bytes blocks. I would like to see configurable block size (at least up to 4k) but as Mikulas pointed out it opens several new problems. Anyway, I do not see reason why crypto accelerators should not process these small sectors better - just hw must be designed for it. Milan