From: Herbert Xu <herbert@gondor.apana.org.au>
To: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: andrew.zaborowski@intel.com, smueller@chronox.de,
linux-crypto@vger.kernel.org
Subject: Re: [RFC PATCH] crypto: RSA padding transform
Date: Tue, 8 Sep 2015 09:07:00 +0800 [thread overview]
Message-ID: <20150908010700.GA4927@gondor.apana.org.au> (raw)
In-Reply-To: <55ED9FDC.60602@intel.com>
Tadeusz Struk <tadeusz.struk@intel.com> wrote:
>
> The more I think about the sgl support the more it looks to me like it wasn't
> a good idea. It will be copied into a flat buffer somewhere along the way anyway.
> Like in the example below.
>
> I have that conversion already done, and for SW it looks like the data is copied 4 times
> for a single operation:
> 1 - from sgl to flat buffer, because MPI doesn't take sgls, (if the src has more ents)
> 2 - from buff to MPI, then, after operation
> 3 - export from MPI to a buff and
> 4 - from buff to sgl (if is the output sg it also fragmented).
>
> I can see now that with all these padding schemes there will be more buffer copied
> on top of this, so I wonder if it still make sense.
> Herbert?
I think it makes sense. Because to implement algif_akcipher
someone will need to do the linearisation anyway. Moreover there
is hardware out there that handles this transparently and we should
not cripple them.
We should add MPI helpers to read/write SG lists which can then
be used by those implementations that need the capability. For
the sake of simplicity you can simply start with a copy but later
we can optimise it to be smarter.
You can always have a fast-path for the case where the SG list is
a single entry.
Cheers,
--
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
next prev parent reply other threads:[~2015-09-08 1:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-05 23:00 [RFC PATCH] crypto: RSA padding transform Andrew Zaborowski
2015-09-06 8:34 ` Stephan Mueller
2015-09-06 14:33 ` Andrzej Zaborowski
2015-09-06 21:17 ` Stephan Mueller
2015-09-07 14:42 ` Andrzej Zaborowski
2015-09-07 15:10 ` Stephan Mueller
2015-09-07 14:31 ` Tadeusz Struk
2015-09-07 17:54 ` Stephan Mueller
2015-09-08 16:09 ` Andrzej Zaborowski
2015-10-30 8:35 ` Marcel Holtmann
2015-09-08 1:07 ` Herbert Xu [this message]
2015-09-07 14:11 ` Tadeusz Struk
2015-09-07 15:07 ` Stephan Mueller
2015-09-07 14:06 ` Tadeusz Struk
2015-09-07 14:38 ` Andrzej Zaborowski
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=20150908010700.GA4927@gondor.apana.org.au \
--to=herbert@gondor.apana.org.au \
--cc=andrew.zaborowski@intel.com \
--cc=linux-crypto@vger.kernel.org \
--cc=smueller@chronox.de \
--cc=tadeusz.struk@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox