On Fri, Feb 23, 2018 at 09:33:33AM +0100, Stephan Müller wrote:
> A simple copy operation, however, will imply that in one AIO recvmsg request,
> only *one* IOCB can be set and processed.
Sure, but the recvmsg will return as soon as the crypto API encrypt
or decrypt function returns. It's still fully async. It's just
that the setup part needs to be done with sendmsg/recvmsg.
Even if we wanted to do what you stated, just inlining the IV isn't
enough. You'd also need to inline the assoclen, and probably the
optype in case you want to mix encrypt/decrypt too.
However, I must say that I don't see the point of going all the way
to support such a bulk submission interface (e.g., lio_listio).
Remember, the algif interface due to its inherent overhead is meant
for bulk data. That is, the processing time for each request is
dominated by the actual processing, not the submission process.
If you're instead processing lots of tiny requests, do NOT use
algif because it's not designed for that.
Therefore spending too much time to optimise the submission overhead
seems pointless to me.
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt