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. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
