From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753700AbcALXko (ORCPT ); Tue, 12 Jan 2016 18:40:44 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:50081 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753320AbcALXkm (ORCPT ); Tue, 12 Jan 2016 18:40:42 -0500 Date: Tue, 12 Jan 2016 23:40:25 +0000 From: Mark Brown To: Mikulas Patocka Cc: device-mapper development , 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, Arnd Bergmann , tj@kernel.org, dan.j.williams@intel.com, Kent Overstreet , Alasdair G Kergon Message-ID: <20160112234025.GF6588@sirena.org.uk> References: <56711C0F.8030105@gmail.com> <56885330.9080801@gmail.com> <20160104201343.GQ16023@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CKsGbYqZLAW+svb0" Content-Disposition: inline In-Reply-To: X-Cookie: APL hackers do it in the quad. User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 2a01:348:6:8808:fab::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --CKsGbYqZLAW+svb0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 12, 2016 at 06:31:19PM -0500, Mikulas Patocka wrote: > On Mon, 4 Jan 2016, Mark Brown wrote: > > The main thing the out of tree req-dm-crypt code is doing was using a > > larger block size which does seem like a reasonable thing to allow > > people to tune for performance tradeofffs but I undertand that's a lot > > harder to achieve in a good way than one might hope. > But as Milan pointed out, that larger block size doesn't work if you=20 > process requests with different sizes - the data encrypted with one=20 > request size won't match if you decrypt them with a different request=20 > size. Sure, you need to fix that block size. > Does the hardware encryption you are optimizing for allow setting=20 > arbitrary tweaks in XTS mode? What is the specific driver you are=20 > optimizing for? This isn't targeted at a specific driver or system, it's trying to make dm-crypt better able to make use of hardware acceleration in general. --CKsGbYqZLAW+svb0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWlY7oAAoJECTWi3JdVIfQwx8H/2Rzv5vE20KBn05CUrja+nkt X4cWPfecFggycjeYIegOEIGUg+4xbVMu7haVLSTWHcNefcOunmljsIWD0+LMFNDI YmSySH43+BLdR6AMnaEWr3ASAz6WGBUh4TJ/coyQk6wdSBqLjp6Hy42D1QmBbsEf Z0Xa/pn6ZbCHKuDNyeEpggY2HmByhhSzSWeLEYXG5e5p4hTA9NM6/astLSPTSLfS WY6R9CpQ5HAUG4i2/FPRxudS5JhhPlZDaq8zrvsHAoeWGZ0YLszTcUArvsCwL9UK fNyM/kvHDfGcg49lZojsiSQ8+mLssHj/SpW1ydAs4u43yeFtkxX91NnDuqV1r8U= =26zk -----END PGP SIGNATURE----- --CKsGbYqZLAW+svb0--