On Tue, 16 Jan 2018 07:28:06 +0100 Stephan Mueller <smueller@xxxxxxxxxx> wrote: > 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 Thanks, I'll take a look at this soonish. Having a busy week. Jonathan > >
