From: Mark Brown <broonie@kernel.org>
To: Milan Broz <gmazyland@gmail.com>
Cc: Baolin Wang <baolin.wang@linaro.org>,
Jens Axboe <axboe@kernel.dk>, Alasdair G Kergon <agk@redhat.com>,
Mike Snitzer <snitzer@redhat.com>,
dm-devel@redhat.com, neilb@suse.com, dan.j.williams@intel.com,
martin.petersen@oracle.com, sagig@mellanox.com,
Kent Overstreet <kent.overstreet@gmail.com>,
keith.busch@intel.com, tj@kernel.org,
Arnd Bergmann <arnd@arndb.de>,
linux-block@vger.kernel.org, linux-raid@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency
Date: Mon, 4 Jan 2016 20:13:43 +0000 [thread overview]
Message-ID: <20160104201343.GQ16023@sirena.org.uk> (raw)
In-Reply-To: <56885330.9080801@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]
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-dependent
> 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.
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-01-04 20:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 3:18 Baolin Wang
2015-12-16 3:18 ` [PATCH v2 1/2] block: Export the __blk_bios_map_sg() to map one bio Baolin Wang
2015-12-16 3:18 ` [PATCH v2 2/2] md: dm-crypt: Introduce the bulk IV mode for bulk crypto Baolin Wang
2015-12-16 8:08 ` [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency Milan Broz
2015-12-16 8:31 ` Baolin Wang
2015-12-17 7:37 ` Baolin Wang
2016-01-02 22:46 ` Milan Broz
2016-01-04 6:58 ` Baolin Wang
2016-01-04 20:13 ` Mark Brown [this message]
2016-01-06 6:49 ` Baolin Wang
2016-01-12 23:31 ` [dm-devel] " Mikulas Patocka
2016-01-12 23:38 ` Arnd Bergmann
2016-01-13 2:18 ` Mikulas Patocka
2016-01-13 10:17 ` Arnd Bergmann
2016-01-13 15:00 ` Mikulas Patocka
2016-01-13 7:01 ` Milan Broz
2016-01-12 23:40 ` Mark Brown
2016-01-13 2:13 ` Mikulas Patocka
2016-01-14 11:35 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160104201343.GQ16023@sirena.org.uk \
--to=broonie@kernel.org \
--cc=agk@redhat.com \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=baolin.wang@linaro.org \
--cc=dan.j.williams@intel.com \
--cc=dm-devel@redhat.com \
--cc=gmazyland@gmail.com \
--cc=keith.busch@intel.com \
--cc=kent.overstreet@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=neilb@suse.com \
--cc=sagig@mellanox.com \
--cc=snitzer@redhat.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®