Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1591110

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

Show all headers | View raw

On Wed, Mar 1, 2017 at 3:21 PM, Ondrej Mosnacek <omosnace@redhat.com> wrote:
> 2017-03-01 13:42 GMT+01:00 Gilad Ben-Yossef <gilad@benyossef.com>:
>
> Wouldn't adopting a bulk request API (something like what I tried to
> do here [1]) that allows users to supply multiple messages, each with
> their own IV, fulfill this purpose? That way, we wouldn't need to
> introduce any new modes into Crypto API and the drivers/accelerators
> would only need to provide bulk implementations of common modes
> (xts(aes), cbc(aes), ...) to provide better performance for dm-crypt
> (and possibly other users, too).
>
> I'm not sure how exactly these crypto accelerators work, but wouldn't
> it help if the drivers simply get more messages (in our case sectors)
> in a single call? I wonder, would (efficiently) supporting such a
> scheme require changes in the HW itself or could it be achieved just
> by modifying driver code (let's say specifically for your CryptoCell
> accelerator)?
>
> [1] https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg23007.html
>


From a general perspective - that is things are expect to be true not
just for CryptoCell but for most HW crypto engines,
you want two things - for the HW engine to be able to burst work for a
long time and than rest for a long time vs. a stop and go scheme
(engine utilization)
and for the average IO transaction to be relatively long (bus utilization)

So, a big cluster size i.e. Milan's proposal) works great - you get both.

Submitting a series of sequential small clusters where the HW can
calculate the IV (e.g. Binoy's proposal) works great if the HW
supports it - you get both.

A batched series of small clusters + IV is less favorable - if your HW
engines has lots of parallel context processing (this is expensive for
HW) you might enjoy engine utilization but the bus utilization will be
low - lots of small transactions.

Gilad


-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Gilad Ben-Yossef <gilad@benyossef.com> - 2017-03-01 09:50 +0100
  Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Milan Broz <gmazyland@gmail.com> - 2017-03-01 10:40 +0100
    Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Gilad Ben-Yossef <gilad@benyossef.com> - 2017-03-01 14:00 +0100
      Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Milan Broz <gmazyland@gmail.com> - 2017-03-01 14:10 +0100
        Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Milan Broz <gmazyland@gmail.com> - 2017-03-01 16:40 +0100
          Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Gilad Ben-Yossef <gilad@benyossef.com> - 2017-03-06 15:40 +0100
      Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Ondrej Mosnacek <omosnace@redhat.com> - 2017-03-01 14:30 +0100
        Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt Gilad Ben-Yossef <gilad@benyossef.com> - 2017-03-02 15:10 +0100

csiph-web