All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: Mark Brown <broonie@kernel.org>
Cc: device-mapper development <dm-devel@redhat.com>,
	Milan Broz <gmazyland@gmail.com>, Jens Axboe <axboe@kernel.dk>,
	keith.busch@intel.com, linux-raid@vger.kernel.org,
	martin.petersen@oracle.com, Mike Snitzer <snitzer@redhat.com>,
	Baolin Wang <baolin.wang@linaro.org>,
	linux-block@vger.kernel.org, neilb@suse.com,
	LKML <linux-kernel@vger.kernel.org>,
	sagig@mellanox.com, Arnd Bergmann <arnd@arndb.de>,
	tj@kernel.org, dan.j.williams@intel.com,
	Kent Overstreet <kent.overstreet@gmail.com>,
	Alasdair G Kergon <agk@redhat.com>
Subject: Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency
Date: Tue, 12 Jan 2016 21:13:19 -0500 (EST)	[thread overview]
Message-ID: <alpine.LRH.2.02.1601122111040.24452@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <20160112234025.GF6588@sirena.org.uk>



On Tue, 12 Jan 2016, Mark Brown wrote:

> 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 
> > process requests with different sizes - the data encrypted with one 
> > request size won't match if you decrypt them with a different request 
> > size.
> 
> Sure, you need to fix that block size.
> 
> > Does the hardware encryption you are optimizing for allow setting 
> > arbitrary tweaks in XTS mode? What is the specific driver you are 
> > 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.

If the hardware acceleration doesn't allow to set arbitrary XTS tweak, 
then this "large block" optimization on XTS can't be done at all.

So, we need to know which driver(s) you want to optimize for and how do 
those driver(s) handle tweak generation.

Mikulas

  reply	other threads:[~2016-01-13  2:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-16  3:18 [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency Baolin Wang
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
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 [this message]
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=alpine.LRH.2.02.1601122111040.24452@file01.intranet.prod.int.rdu2.redhat.com \
    --to=mpatocka@redhat.com \
    --cc=agk@redhat.com \
    --cc=arnd@arndb.de \
    --cc=axboe@kernel.dk \
    --cc=baolin.wang@linaro.org \
    --cc=broonie@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.