From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753620AbcADUON (ORCPT ); Mon, 4 Jan 2016 15:14:13 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:35824 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753224AbcADUOI (ORCPT ); Mon, 4 Jan 2016 15:14:08 -0500 Date: Mon, 4 Jan 2016 20:13:43 +0000 From: Mark Brown To: Milan Broz Cc: Baolin Wang , Jens Axboe , Alasdair G Kergon , Mike Snitzer , dm-devel@redhat.com, neilb@suse.com, dan.j.williams@intel.com, martin.petersen@oracle.com, sagig@mellanox.com, Kent Overstreet , keith.busch@intel.com, tj@kernel.org, Arnd Bergmann , linux-block@vger.kernel.org, linux-raid@vger.kernel.org, LKML Message-ID: <20160104201343.GQ16023@sirena.org.uk> References: <56711C0F.8030105@gmail.com> <56885330.9080801@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wHwaWyh5/fUA7Dm/" Content-Disposition: inline In-Reply-To: <56885330.9080801@gmail.com> X-Cookie: Honk if you love peace and quiet. 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: [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 --wHwaWyh5/fUA7Dm/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 02, 2016 at 11:46:08PM +0100, Milan Broz wrote: > Anyway, I think that you should optimize driver, not add strange hw-depen= dent > crypto modes to dmcrypt. This is not the first crypto accelerator that is= just not > suited for this kind of use. > (If it can process batch of chunks of data each with own IV, then it can = work > with dmcrypt, but I think such optimized code should be inside crypto API, > not in dmcrypt.) The flip side of this is there is an awful lot of hardware out there that has basically this pattern and if we can make the difference between people being able to encrypt or not encrypt their storage due to performance then that seems like a win. Getting hardware changes isn't going to be a fast process. From a brief look at the crypto layer it does look there may be things we can do there, if only in terms of factoring out the common patterns for driving the queue of operations into the hardware so it's easy for drivers to do the best thing. =20 One thing that occurs to me for the IV programming that has been proposed for SPI by Martin Sparl (and seen good results on Raspberry PI) is to insert transfers programming the crypto engine into the stream of DMA operations so we can keep the hardware busy. It won't work with every SoC out there but it will work with a lot of them, it's what hardware that explicitly supports this will be doing internally. It's the sort of thing that would benefit from factoring out, it's a lot of hassle to implement per driver. 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. --wHwaWyh5/fUA7Dm/ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWitJ2AAoJECTWi3JdVIfQ33YH/1d/G6DQGa49xEi7UUxjekRW GhxVr+EavcII7O0qptSoDjekzvjGKzWwxiS1WHY/1omD8PzHMSfkWCcap1UkRVOk AoNPkULpeYOT/VqxQXLHHZzyn8Oki9txan3mESIiyoQyyXYsb6bjc6i9OzcBXcPB bJGYKRlzXVkf/NmzLkeJnRrQ5BpgmsfnS1EquQVILV0y3uhnt7wVhnNLuE8+hSZR vkzSHhssGrVjX1QhlPbWsT54rcPLcIREVxak+9AtCyOv9RAIQlBbEPk80TX80ST2 a8vWFNmlffrvvLEPnjqA/iNmiDxu6WvKlQblr/Bs21pHgYcCBZZh6GqyI7mO+1E= =zudk -----END PGP SIGNATURE----- --wHwaWyh5/fUA7Dm/--