All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Ondrej Mosnacek <omosnace@redhat.com>
Cc: dm-devel@redhat.com, mpatocka@redhat.com,
	linux-crypto@vger.kernel.org, omosnace@redhat.com
Subject: Re: [PATCH] crypto: xts - Drop use of auxiliary buffer
Date: Tue, 4 Sep 2018 11:38:16 +0800	[thread overview]
Message-ID: <20180904033815.3titfipifya2zg7r@gondor.apana.org.au> (raw)
In-Reply-To: <20180903112942.18979-1-omosnace@redhat.com>

Ondrej Mosnacek <omosnace@redhat.com> wrote:
> Hi Herbert, Mikulas,
> 
> I noticed the discussion about using kmalloc() inside crypto code and it
> made me wonder if the code in xts.c can actually be simplified to not
> require kmalloc() at all, while not badly affecting performace. I played
> around with it a little and it turns out we can drop the whole caching
> of tweak blocks, reducing code size by ~200 lines and not only preserve,
> but even improve the performance in some cases. See the full patch
> below.
> 
> Obviously, this doesn't solve the general issue of using kmalloc() in
> crypto API routines, but it does resolve the original reported problem
> and also makes the XTS code easier to maintain.

Nice work.  Unfortunately it doesn't apply against the latest
cryptodev tree.  Please rebase and resubmit.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

WARNING: multiple messages have this Message-ID (diff)
From: Herbert Xu <herbert@gondor.apana.org.au>
Cc: dm-devel@redhat.com, mpatocka@redhat.com,
	linux-crypto@vger.kernel.org, omosnace@redhat.com
Subject: Re: [PATCH] crypto: xts - Drop use of auxiliary buffer
Date: Tue, 4 Sep 2018 11:38:16 +0800	[thread overview]
Message-ID: <20180904033815.3titfipifya2zg7r@gondor.apana.org.au> (raw)
In-Reply-To: <20180903112942.18979-1-omosnace@redhat.com>

Ondrej Mosnacek <omosnace@redhat.com> wrote:
> Hi Herbert, Mikulas,
> 
> I noticed the discussion about using kmalloc() inside crypto code and it
> made me wonder if the code in xts.c can actually be simplified to not
> require kmalloc() at all, while not badly affecting performace. I played
> around with it a little and it turns out we can drop the whole caching
> of tweak blocks, reducing code size by ~200 lines and not only preserve,
> but even improve the performance in some cases. See the full patch
> below.
> 
> Obviously, this doesn't solve the general issue of using kmalloc() in
> crypto API routines, but it does resolve the original reported problem
> and also makes the XTS code easier to maintain.

Nice work.  Unfortunately it doesn't apply against the latest
cryptodev tree.  Please rebase and resubmit.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

  reply	other threads:[~2018-09-04  3:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-03 11:29 [PATCH] crypto: xts - Drop use of auxiliary buffer Ondrej Mosnacek
2018-09-04  3:38 ` Herbert Xu [this message]
2018-09-04  3:38   ` Herbert Xu

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=20180904033815.3titfipifya2zg7r@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=dm-devel@redhat.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=omosnace@redhat.com \
    /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.