Am Freitag, 23. Februar 2018, 13:00:26 CET schrieb Herbert Xu: Hi Herbert, > 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. Wouldn't a copy of the ctx->iv into a per-request buffer change the behavoir of the AF_ALG interface significantly? Today, if multiple IOCBs are submitted, most cipher implementations would serialize the requests (e.g. all implementations that behave synchronous in nature like all software implementations). Thus, when copying the ctx->iv into a separate per-request buffer, suddenly all block-chained cipher operations are not block chained any more. > > 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. Maybe that is what we have to do. > > 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). IMHO, the point is that AF_ALG is the only interface to allow userspace to utilize hardware crypto implementations. For example, on a small chip with hardware crypto support, your user space code can offload crypto to that hardware to free CPU time. How else would somebody access its crypto accelerators? > > 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. I see that. And for smaller chips with crypto support, this would be the case IMHO. Especially if we streamline the AF_ALG overhead such that we reduce the number of syscalls and user/kernel space roundtrips. > > If you're instead processing lots of tiny requests, do NOT use > algif because it's not designed for that. The only issue in this case is that it makes the operation slower. > > Therefore spending too much time to optimise the submission overhead > seems pointless to me. > > Cheers, Ciao Stephan
