Am Montag, 15. Januar 2018, 15:42:58 CET schrieb Jonathan Cameron: Hi Jonathan, > > What about: > > > > sendmsg(IV, data) > > sendmsg(data) > > .. > > AIO recvmsg with multiple IOCBs > > AIO recvmsg with multiple IOCBs > > .. > > sendmsg(IV, data) > > .. > > > > This implies, however, that before the sendmsg with the second IV is sent, > > all AIO operations from the first invocation would need to be finished. > Yes that works fine, but rather restricts the flow - you would end up > waiting until you could concatenate a bunch of data in userspace so as to > trade off against the slow down whenever you need to synchronize back up to > userspace. I think the solution is already present and even libkcapi's architecture is set up to handle this scenario: We have 2 types of FDs: one obtained from socket() and one from accept(). The socket-FD is akin to the TFM. The accept FD is exactly what you want: tfmfd = socket() setkey(tfmfd) opfd = accept() opfd2 = accept() sendmsg(opfd, IV, data) recvmsg(opfd, data) sendmsg(opfd2, IV, data) recvmsg(opfd2, data) sendmsg(opfd, data) .. There can be multipe FDs from accept and these are the "identifiers" for your cipher operation stream that belongs together. libkcapi has already the architecture for this type of work, but it is not exposed to the API yet. The internal calls for sendmsg/recvmsg all take an (op)FD parameter. E.g. _kcapi_common_send_meta_fd has the fdptr variable. internal.h currently wraps this call into _kcapi_common_send_meta where the handle->opfd variable is used. The idea why I implemented that is because the caller could maintain an array of opfds. If we would expose these internal calls with the FD argument, you can maintain multiple opfds implementing your use case. The only change would be to expose the internal libkcapi calls. Ciao Stephan
