* RE: [PATCH] virtio-crypto: adjust priority of algorithm
From: Gonglei (Arei) @ 2017-01-13 9:24 UTC (permalink / raw)
To: Christian Borntraeger, virtualization@lists.linux-foundation.org,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: herbert@gondor.apana.org.au, mst@redhat.com
In-Reply-To: <874ee338-4dd6-8a2c-fb95-59bd784de026@de.ibm.com>
>
> From: Christian Borntraeger [mailto:borntraeger@de.ibm.com]
> Sent: Friday, January 13, 2017 4:28 PM
> To: Gonglei (Arei); virtualization@lists.linux-foundation.org;
> linux-crypto@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: mst@redhat.com; herbert@gondor.apana.org.au
> Subject: Re: [PATCH] virtio-crypto: adjust priority of algorithm
>
> ACK. Whoever takes this patch might want to fixup 3 typos.
>
Thanks, I'd better send v2 IMHO. :)
Regards,
-Gonglei
> On 01/13/2017 07:25 AM, Gonglei wrote:
>
> > Some hardware accelerators (like intel aseni or the s390
> aesni
> > cpacf functions) have lower priorities than virtio
> > crypto, and those drivers are faster than the same in
> > the host via virtio. So let's lower the priority of
> > virtio-crypto's algorithm, make it's higher than sofeware
> software
> > implimentations but lower than the hardware ones.
> implementations
> >
> > Suggested-by: Christian Borntraeger <borntraeger@de.ibm.com>
> > Signed-off-by: Gonglei <arei.gonglei@huawei.com>
> > ---
> > drivers/crypto/virtio/virtio_crypto_algs.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c
> b/drivers/crypto/virtio/virtio_crypto_algs.c
> > index 6f40a42..4de4740 100644
> > --- a/drivers/crypto/virtio/virtio_crypto_algs.c
> > +++ b/drivers/crypto/virtio/virtio_crypto_algs.c
> > @@ -498,7 +498,7 @@ void virtio_crypto_ablkcipher_finalize_req(
> > static struct crypto_alg virtio_crypto_algs[] = { {
> > .cra_name = "cbc(aes)",
> > .cra_driver_name = "virtio_crypto_aes_cbc",
> > - .cra_priority = 501,
> > + .cra_priority = 150,
> > .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
> > .cra_blocksize = AES_BLOCK_SIZE,
> > .cra_ctxsize = sizeof(struct virtio_crypto_ablkcipher_ctx),
> >
^ permalink raw reply
* [PATCH v2] virtio-crypto: adjust priority of algorithm
From: Gonglei @ 2017-01-13 9:34 UTC (permalink / raw)
To: virtualization, linux-crypto, linux-kernel
Cc: mst, herbert, borntraeger, Gonglei
Some hardware accelerators (like intel aesni or the s390
cpacf functions) have lower priorities than virtio
crypto, and those drivers are faster than the same in
the host via virtio. So let's lower the priority of
virtio-crypto's algorithm, make it's higher than software
implementations but lower than the hardware ones.
Suggested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
v2:
fix three typos. [Christian]
---
drivers/crypto/virtio/virtio_crypto_algs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/virtio/virtio_crypto_algs.c b/drivers/crypto/virtio/virtio_crypto_algs.c
index 6f40a42..4de4740 100644
--- a/drivers/crypto/virtio/virtio_crypto_algs.c
+++ b/drivers/crypto/virtio/virtio_crypto_algs.c
@@ -498,7 +498,7 @@ void virtio_crypto_ablkcipher_finalize_req(
static struct crypto_alg virtio_crypto_algs[] = { {
.cra_name = "cbc(aes)",
.cra_driver_name = "virtio_crypto_aes_cbc",
- .cra_priority = 501,
+ .cra_priority = 150,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct virtio_crypto_ablkcipher_ctx),
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management
From: Herbert Xu @ 2017-01-13 10:21 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <5211147.RjDSfvrhhz@tauon.atsec.com>
On Thu, Jan 12, 2017 at 05:19:57PM +0100, Stephan Müller wrote:
>
> > I don't understand, what's wrong with:
> >
> > sendmsg(fd, ...)
> > aio_read(iocb1)
> > sendmsg(fd, ...)
> > aio_read(iocb2)
>
> Sure, that works. But here you limit yourself to one IOCB per aio_read. But
> aio_read supports multiple IOCBs in one invocation. And this is the issue I am
> considering.
Not really. You just lay it out in the same way with lio_listio.
That is, a write followed by read, etc.
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
^ permalink raw reply
* Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers
From: Herbert Xu @ 2017-01-13 10:23 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <3463059.TVfkfLOfNf@tauon.atsec.com>
On Thu, Jan 12, 2017 at 05:37:33PM +0100, Stephan Müller wrote:
>
> I would not understand that statement.
>
> With the patch mentioned above that I provided some weeks ago, we have the
> following scenario for an encryption (in case of decryption, it is almost
> identical, just the tag location is reversed):
>
> user calls sendmsg with data buffer/IOVEC: AAD || PT
> -> algif_aead turns this into the src SGL
>
> user calls recvmsg with data buffer/IOVEC: CT || Tag
> -> algif_aead creates the first SG entry in the dst SGL pointing to the
> AAD from the src SGL
> -> algif_aead appends the user buffers to the dst SGL
>
> -> algif_aead performs its operation and during that operation, only the
> CT and Tag parts are changed
>
> I.e. with the pre-pending of the SG pointing to the AAD from the src SGL to
> the dst SGL we have a clean invocation of the kernel API.
But that means you can never invoke the in-place path of the kernel
API, which is the most optimised code path.
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
^ permalink raw reply
* Re: [PATCH v2 0/7] crypto: ARM/arm64 - AES and ChaCha20 updates for v4.11
From: Herbert Xu @ 2017-01-13 10:28 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAKv+Gu9a5ZsWtT0XYczPBf54L7d5Whu5gG1eUOt8T-wms0orbg@mail.gmail.com>
On Thu, Jan 12, 2017 at 04:48:08PM +0000, Ard Biesheuvel wrote:
>
> Actually, patch #6 was the huge one not #7, and I don't see it in your tree yet.
>
> https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git/commit/?h=crypto-arm-v4.11&id=cbf03b255f7c
>
> The order does not matter, though, so could you please put it on top? Thanks.
OK I've applied it now and will push out soon.
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
^ permalink raw reply
* Re: [RFC PATCH 0/6] Add bulk skcipher requests to crypto API and dm-crypt
From: Herbert Xu @ 2017-01-13 10:41 UTC (permalink / raw)
To: Ondrej Mosnacek
Cc: linux-crypto, dm-devel, Mike Snitzer, Milan Broz, Mikulas Patocka,
Binoy Jayan
In-Reply-To: <cover.1484215956.git.omosnacek@gmail.com>
On Thu, Jan 12, 2017 at 01:59:52PM +0100, Ondrej Mosnacek wrote:
>
> the goal of this patchset is to allow those skcipher API users that need to
> process batches of small messages (especially dm-crypt) to do so efficiently.
Please explain why this can't be done with the existing framework
using IV generators similar to the ones used for IPsec.
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
^ permalink raw reply
* Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management
From: Stephan Müller @ 2017-01-13 10:49 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20170113102145.GA23349@gondor.apana.org.au>
Am Freitag, 13. Januar 2017, 18:21:45 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 05:19:57PM +0100, Stephan Müller wrote:
> > > I don't understand, what's wrong with:
> > >
> > > sendmsg(fd, ...)
> > > aio_read(iocb1)
> > > sendmsg(fd, ...)
> > > aio_read(iocb2)
> >
> > Sure, that works. But here you limit yourself to one IOCB per aio_read.
> > But
> > aio_read supports multiple IOCBs in one invocation. And this is the issue
> > I am considering.
>
> Not really. You just lay it out in the same way with lio_listio.
> That is, a write followed by read, etc.
According to the man page of lio_listio(3) the provided AIO operations are
executed in an unspecified order. I would infer from that statement that even
if an order of write / read / write / read is defined by the caller, this
order may not be followed by the kernel. Thus we would need to consider the
case that in the end, algif has to process the order of write / write / read /
read or any other order.
Besides, the crashes I reported for the current AIO implementation in
algif_aead and algif_skcipher are always triggered when invoking an aio_read
with two or more IOCBs. The most important aspect I want to cover with the
patch set is to stop crashing the kernel.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers
From: Stephan Müller @ 2017-01-13 10:58 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20170113102339.GB23349@gondor.apana.org.au>
Am Freitag, 13. Januar 2017, 18:23:39 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 05:37:33PM +0100, Stephan Müller wrote:
> > I would not understand that statement.
> >
> > With the patch mentioned above that I provided some weeks ago, we have the
> > following scenario for an encryption (in case of decryption, it is almost
> > identical, just the tag location is reversed):
> >
> > user calls sendmsg with data buffer/IOVEC: AAD || PT
> >
> > -> algif_aead turns this into the src SGL
> >
> > user calls recvmsg with data buffer/IOVEC: CT || Tag
> >
> > -> algif_aead creates the first SG entry in the dst SGL pointing to the
> >
> > AAD from the src SGL
> >
> > -> algif_aead appends the user buffers to the dst SGL
> >
> > -> algif_aead performs its operation and during that operation, only the
> >
> > CT and Tag parts are changed
> >
> > I.e. with the pre-pending of the SG pointing to the AAD from the src SGL
> > to
> > the dst SGL we have a clean invocation of the kernel API.
>
> But that means you can never invoke the in-place path of the kernel
> API, which is the most optimised code path.
May I ask how the in-place code path can be invoked by algif_aead or
algif_skcipher? As far as I understand, this code path is only invoked when
the cipher implementation sees that the src and dst SGLs are identical.
However, both algif interfaces maintain separate src and dst SGLs and always
invoke the cipher operation with these dissimilar SGLs. Thus, I would infer
that even when the user invokes zerocopy, the src/dst SGLs are not identical
and therefore the cipher implementations would not use the in-place code path.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management
From: Herbert Xu @ 2017-01-13 11:03 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <1588177.ehMkkoOMrj@positron.chronox.de>
On Fri, Jan 13, 2017 at 11:49:05AM +0100, Stephan Müller wrote:
>
> According to the man page of lio_listio(3) the provided AIO operations are
> executed in an unspecified order. I would infer from that statement that even
> if an order of write / read / write / read is defined by the caller, this
> order may not be followed by the kernel. Thus we would need to consider the
> case that in the end, algif has to process the order of write / write / read /
> read or any other order.
Well if ordering is not guaranteed that I don't see how your code
can work either. Or am I missing something?
> Besides, the crashes I reported for the current AIO implementation in
> algif_aead and algif_skcipher are always triggered when invoking an aio_read
> with two or more IOCBs. The most important aspect I want to cover with the
> patch set is to stop crashing the kernel.
Please stop adding new features and just fix the existing crash.
Once we have that covered and backported to stable then we can
start addressing new features.
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
^ permalink raw reply
* Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management
From: Stephan Müller @ 2017-01-13 11:10 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20170113110335.GA23617@gondor.apana.org.au>
Am Freitag, 13. Januar 2017, 19:03:35 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 11:49:05AM +0100, Stephan Müller wrote:
> > According to the man page of lio_listio(3) the provided AIO operations are
> > executed in an unspecified order. I would infer from that statement that
> > even if an order of write / read / write / read is defined by the caller,
> > this order may not be followed by the kernel. Thus we would need to
> > consider the case that in the end, algif has to process the order of
> > write / write / read / read or any other order.
>
> Well if ordering is not guaranteed that I don't see how your code
> can work either. Or am I missing something?
The patch simply stores all data it gets from sendmsg in the src SGL. In
addition it maintains an offset pointer into that src SGLs.
When the recvmsg call comes in and the dst SGL is prepared, it simply takes as
much data from the src SGL as needed to cover the request defined by the dst
SGL. After completing that operation, the offset pointer is moved forward to
point to a yet unused part of the src SGL. If another recvmsg comes in without
an intermediate sendmsg, it simply starts using the data from the src SGL
starting from the offset.
Therefore, the code should now be able to handle a write / write / read / read
scenario. Or it can handle, say, a write(32 bytes) / read (16 bytes) / read
(16 bytes). At least my tests covered a successful testing of that scenario
which always crashed the kernel before.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers
From: Stephan Müller @ 2017-01-13 11:12 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20170113110417.GB23617@gondor.apana.org.au>
Am Freitag, 13. Januar 2017, 19:04:17 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 11:58:24AM +0100, Stephan Müller wrote:
> > May I ask how the in-place code path can be invoked by algif_aead or
> > algif_skcipher? As far as I understand, this code path is only invoked
> > when
> > the cipher implementation sees that the src and dst SGLs are identical.
>
> It's not right now but it isn't difficult to add the code to allow
> it by comparing SGLs.
Adding such code should IMHO not be impaired by pointing to the AAD held in
the src SGL by the dst SGL as offered with the older patch mentioned before.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management
From: Herbert Xu @ 2017-01-13 11:12 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <5603535.pO8F2Xs7xC@positron.chronox.de>
On Fri, Jan 13, 2017 at 12:10:02PM +0100, Stephan Müller wrote:
>
> > Well if ordering is not guaranteed that I don't see how your code
> > can work either. Or am I missing something?
>
> The patch simply stores all data it gets from sendmsg in the src SGL. In
> addition it maintains an offset pointer into that src SGLs.
>
> When the recvmsg call comes in and the dst SGL is prepared, it simply takes as
> much data from the src SGL as needed to cover the request defined by the dst
> SGL. After completing that operation, the offset pointer is moved forward to
> point to a yet unused part of the src SGL. If another recvmsg comes in without
> an intermediate sendmsg, it simply starts using the data from the src SGL
> starting from the offset.
>
> Therefore, the code should now be able to handle a write / write / read / read
> scenario. Or it can handle, say, a write(32 bytes) / read (16 bytes) / read
> (16 bytes). At least my tests covered a successful testing of that scenario
> which always crashed the kernel before.
Are you making separate read calls or just a single one? If you're
making separate calls, then this is no differnt to just doing
write/read pairs. You're not saving any overhead.
If you're making a single call, what guarantees the ordering?
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
^ permalink raw reply
* Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers
From: Herbert Xu @ 2017-01-13 11:14 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <1593277.7QY5i6DVS0@positron.chronox.de>
On Fri, Jan 13, 2017 at 12:12:39PM +0100, Stephan Müller wrote:
>
> Adding such code should IMHO not be impaired by pointing to the AAD held in
> the src SGL by the dst SGL as offered with the older patch mentioned before.
The point is you're turning what could otherwise be a linear SGL
into a non-linear one by forcing the same AAD on both sides.
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
^ permalink raw reply
* Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management
From: Stephan Müller @ 2017-01-13 11:16 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20170113111259.GA23800@gondor.apana.org.au>
Am Freitag, 13. Januar 2017, 19:12:59 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 12:10:02PM +0100, Stephan Müller wrote:
> > > Well if ordering is not guaranteed that I don't see how your code
> > > can work either. Or am I missing something?
> >
> > The patch simply stores all data it gets from sendmsg in the src SGL. In
> > addition it maintains an offset pointer into that src SGLs.
> >
> > When the recvmsg call comes in and the dst SGL is prepared, it simply
> > takes as much data from the src SGL as needed to cover the request
> > defined by the dst SGL. After completing that operation, the offset
> > pointer is moved forward to point to a yet unused part of the src SGL. If
> > another recvmsg comes in without an intermediate sendmsg, it simply
> > starts using the data from the src SGL starting from the offset.
> >
> > Therefore, the code should now be able to handle a write / write / read /
> > read scenario. Or it can handle, say, a write(32 bytes) / read (16 bytes)
> > / read (16 bytes). At least my tests covered a successful testing of that
> > scenario which always crashed the kernel before.
>
> Are you making separate read calls or just a single one? If you're
> making separate calls, then this is no differnt to just doing
> write/read pairs. You're not saving any overhead.
I make one read call.
>
> If you're making a single call, what guarantees the ordering?
Technically, io_submit is the syscall that triggers the recvmsg. Are you
saying that this syscall does not maintain ordering? At least the man page
does not add any hints that it would not (unlike the lio_list man page).
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers
From: Stephan Müller @ 2017-01-13 11:19 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20170113111406.GB23800@gondor.apana.org.au>
Am Freitag, 13. Januar 2017, 19:14:06 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 12:12:39PM +0100, Stephan Müller wrote:
> > Adding such code should IMHO not be impaired by pointing to the AAD held
> > in
> > the src SGL by the dst SGL as offered with the older patch mentioned
> > before.
> The point is you're turning what could otherwise be a linear SGL
> into a non-linear one by forcing the same AAD on both sides.
That is correct, but I thought that playing with pointers is always faster
than doing memcpy. Are you saying that this assumption is not true when we
somehow have the code to try to perform an in-place operation?
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management
From: Herbert Xu @ 2017-01-13 11:25 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <2278925.gEXngSfgVI@positron.chronox.de>
On Fri, Jan 13, 2017 at 12:16:27PM +0100, Stephan Müller wrote:
>
> > If you're making a single call, what guarantees the ordering?
>
> Technically, io_submit is the syscall that triggers the recvmsg. Are you
> saying that this syscall does not maintain ordering? At least the man page
> does not add any hints that it would not (unlike the lio_list man page).
The code certainly does. But my point is that you can do the
same thing using the current API. Just make your list be pairs
of write/read and it should work.
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
^ permalink raw reply
* Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers
From: Herbert Xu @ 2017-01-13 11:26 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <2328881.s8hPz576Kn@positron.chronox.de>
On Fri, Jan 13, 2017 at 12:19:48PM +0100, Stephan Müller wrote:
>
> That is correct, but I thought that playing with pointers is always faster
> than doing memcpy. Are you saying that this assumption is not true when we
> somehow have the code to try to perform an in-place operation?
If you're doing crypto the overhead in copying the AAD is the
last thing you need to worry about.
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
^ permalink raw reply
* Re: [RFC PATCH 5/6] crypto: aesni-intel - Add bulk request support
From: Ondrej Mosnáček @ 2017-01-13 11:27 UTC (permalink / raw)
To: Eric Biggers
Cc: Herbert Xu, linux-crypto, dm-devel, Mike Snitzer, Milan Broz,
Mikulas Patocka, Binoy Jayan
In-Reply-To: <20170113031933.GA4956@zzz>
Hi Eric,
2017-01-13 4:19 GMT+01:00 Eric Biggers <ebiggers3@gmail.com>:
> To what extent does the performance benefit of this patchset result from just
> the reduced numbers of calls to kernel_fpu_begin() and kernel_fpu_end()?
>
> If it's most of the benefit, would it make any sense to optimize
> kernel_fpu_begin() and kernel_fpu_end() instead?
>
> And if there are other examples besides kernel_fpu_begin/kernel_fpu_end where
> the bulk API would provide a significant performance boost, can you mention
> them?
In the case of AES-NI ciphers, this is the only benefit. However, this
change is not intended solely (or primarily) for AES-NI ciphers, but
also for other drivers that have a high per-request overhead.
This patchset is in fact a reaction to Binoy Jayan's efforts (see
[1]). The problem with small requests to HW crypto drivers comes up
for example in Qualcomm's Android [2], where they actually hacked
together their own version of dm-crypt (called 'dm-req-crypt'), which
in turn used a driver-specific crypto mode, which does the IV
generation on its own, and thereby is able to process several sectors
at once. The goal is to extend the crypto API so that vendors don't
have to roll out their own workarounds to have efficient disk
encryption.
> Interestingly, the arm64 equivalent to kernel_fpu_begin()
> (kernel_neon_begin_partial() in arch/arm64/kernel/fpsimd.c) appears to have an
> optimization where the SIMD registers aren't saved if they were already saved.
> I wonder why something similar isn't done on x86.
AFAIK, there can't be done much about the kernel_fpu_* functions, see e.g. [3].
Regards,
Ondrej
[1] https://lkml.org/lkml/2016/12/20/111
[2] https://nelenkov.blogspot.com/2015/05/hardware-accelerated-disk-encryption-in.html
[3] https://lkml.org/lkml/2016/12/21/354
>
> Eric
^ permalink raw reply
* (unknown),
From: service @ 2017-01-13 11:28 UTC (permalink / raw)
To: linux-crypto
[-- Attachment #1: INFO_4883709289_linux-crypto.zip --]
[-- Type: application/zip, Size: 45688 bytes --]
^ permalink raw reply
* Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers
From: Herbert Xu @ 2017-01-13 11:04 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <9279288.fr5DIlfFLr@positron.chronox.de>
On Fri, Jan 13, 2017 at 11:58:24AM +0100, Stephan Müller wrote:
>
> May I ask how the in-place code path can be invoked by algif_aead or
> algif_skcipher? As far as I understand, this code path is only invoked when
> the cipher implementation sees that the src and dst SGLs are identical.
It's not right now but it isn't difficult to add the code to allow
it by comparing SGLs.
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
^ permalink raw reply
* Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers
From: Stephan Müller @ 2017-01-13 11:30 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20170113112623.GB23928@gondor.apana.org.au>
Am Freitag, 13. Januar 2017, 19:26:23 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 12:19:48PM +0100, Stephan Müller wrote:
> > That is correct, but I thought that playing with pointers is always faster
> > than doing memcpy. Are you saying that this assumption is not true when we
> > somehow have the code to try to perform an in-place operation?
>
> If you're doing crypto the overhead in copying the AAD is the
> last thing you need to worry about.
So, the patch set you want to see is:
- remove the AAD copy operation from authenc and not add it to any AEAD
implementations
- add the AAD copy operation to algif_aead
Shall the null cipher context we need for that be anchored in the crypto_aead
data structure as done in patch 01 of this series (this would allow an easy
addition to the copy call to every AEAD implementation if deemed needed) or
shall it be anchored within algif_aead?
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers
From: Herbert Xu @ 2017-01-13 11:33 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <1704568.lHqrOxcchT@positron.chronox.de>
On Fri, Jan 13, 2017 at 12:30:15PM +0100, Stephan Müller wrote:
>
> So, the patch set you want to see is:
>
> - remove the AAD copy operation from authenc and not add it to any AEAD
> implementations
Why would you remove it from authenc?
> - add the AAD copy operation to algif_aead
No just copy everything and then do in-place crypto.
> Shall the null cipher context we need for that be anchored in the crypto_aead
> data structure as done in patch 01 of this series (this would allow an easy
> addition to the copy call to every AEAD implementation if deemed needed) or
> shall it be anchored within algif_aead?
It should be in algif_aead.
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
^ permalink raw reply
* Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers
From: Herbert Xu @ 2017-01-13 11:39 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <2829634.RJknVxGPvY@positron.chronox.de>
On Fri, Jan 13, 2017 at 12:36:56PM +0100, Stephan Müller wrote:
>
> I thought I understood that you would not want to see it in any
> implementation. But, ok, if you want to leave it.
If you remove it from authenc then authenc will be broken.
--
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
^ permalink raw reply
* Re: [PATCH 00/13] crypto: copy AAD during encrypt for AEAD ciphers
From: Stephan Müller @ 2017-01-13 11:36 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20170113113324.GA24021@gondor.apana.org.au>
Am Freitag, 13. Januar 2017, 19:33:24 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 12:30:15PM +0100, Stephan Müller wrote:
> > So, the patch set you want to see is:
> >
> > - remove the AAD copy operation from authenc and not add it to any AEAD
> > implementations
>
> Why would you remove it from authenc?
I thought I understood that you would not want to see it in any
implementation. But, ok, if you want to leave it.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 1/2] crypto: aead AF_ALG - overhaul memory management
From: Stephan Müller @ 2017-01-13 11:51 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20170113112539.GA23928@gondor.apana.org.au>
Am Freitag, 13. Januar 2017, 19:25:39 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 12:16:27PM +0100, Stephan Müller wrote:
> > > If you're making a single call, what guarantees the ordering?
> >
> > Technically, io_submit is the syscall that triggers the recvmsg. Are you
> > saying that this syscall does not maintain ordering? At least the man page
> > does not add any hints that it would not (unlike the lio_list man page).
>
> The code certainly does. But my point is that you can do the
> same thing using the current API. Just make your list be pairs
> of write/read and it should work.
How shall these pairs come into existence? The read/write system calls may
come at unspecified times with potentially dissimilar buffer lengths.
Ciao
Stephan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox