On Tue, Jan 13, 2015 at 12:28:23PM -0800, Tadeusz Struk wrote:
The way the algif_skcipher works currently is that on sendmsg/sendpage it
builds an sgl for the input data and then on read/recvmsg it sends the job
for encryption putting the user to sleep till the data is processed.
This way it can only handle one job at a given time.
This patch changes it to be asynchronous.
The idea is to allow enqueue multiple jobs to get most of available crypto HW
accelerators and then read when the data is processed without blocking.
To allow that both the input and output sgl need to be know at sendmsg/sendpage
or the operation needs to happen "in place" in the input sgl. The approach here
is to use the "in place" operation and process the data in the sgl provided in
sendmsg. To allow that new user visible flags are introduced:
ALG_SET_OP_TYPE
ALG_OP_OUTOF_PLACE
ALG_OP_IN_PLACE
By default the operation type is ALG_OP_OUTOF_PLACE, which works the same way as
without the change and allows existing application working without any update.
Using the test application from https://lkml.org/lkml/2011/8/28/87 with small
modification to support in place operation, and reading after every 16th
sendmsg these are the results:
What you want is AIO so we should try to use that interface rather
than creating some funky crypto-specific interface.
Dave, the AIO hooks in net/socket.c is currently simply pointing
to the sync implementation. What are you thoughts on allowing
socket implementations to supply these hooks?
The algif interface can then use these hooks to implement AIO
which is useful for maximising the hardware performance without
resorting to loads of threads.
Cheers,
--
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Herbert,
On 01/13/2015 09:38 PM, Herbert Xu wrote:
What you want is AIO so we should try to use that interface rather
than creating some funky crypto-specific interface.
Dave, the AIO hooks in net/socket.c is currently simply pointing
to the sync implementation. What are you thoughts on allowing
socket implementations to supply these hooks?
The algif interface can then use these hooks to implement AIO
which is useful for maximising the hardware performance without
resorting to loads of threads.
But then would you like to extend AIO interface to take the IV and
something that would indicate the encrypt/decrypt operation on
aio_write()? Also as far as I can see AIO doesn't support splice()
operation for zero copy, which is the main thing here.
From the other hand it shouldn't be a problem to add crypto specific
stuff to include/uapi/linux/if_alg.h, because it is all about crypto
anyway, is it not?
If you have a better way how to indicate that data processing should
start on the last page in sendpage() instead of ALG_OP_IN_PLACE I would
be happy to use it.
Thanks,
Tadeusz
On Wed, Jan 14, 2015 at 09:36:57AM -0800, Tadeusz Struk wrote:
But then would you like to extend AIO interface to take the IV and
something that would indicate the encrypt/decrypt operation on
aio_write()? Also as far as I can see AIO doesn't support splice()
Any metadata such as the IV can still go through the existing
sendmsg interface, just as you would do a sendmsg before a sendfile
to set things up.
operation for zero copy, which is the main thing here.
The AIO interface itself can accomodate zero-copy. It's just that
we currently don't have any support for it in the network socket
API.
quoted
From the other hand it shouldn't be a problem to add crypto specific
stuff to include/uapi/linux/if_alg.h, because it is all about crypto
anyway, is it not?
Yes but you're violating the meaning of sendpage(). The latter
is not crypto-specific so you shouldn't be adding things that
prevent future optimisations to it.
Cheers,
--
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt