On 6/28/22 9:02 AM, Dylan Yudaken wrote: > This series adds support for multishot recv/recvmsg to io_uring. > > The idea is that generally socket applications will be continually > enqueuing a new recv() when the previous one completes. This can be > improved on by allowing the application to queue a multishot receive, > which will post completions as and when data is available. It uses the > provided buffers feature to receive new data into a pool provided by > the application. > > This is more performant in a few ways: > * Subsequent receives are queued up straight away without requiring the > application to finish a processing loop. > * If there are more data in the socket (sat the provided buffer > size is smaller than the socket buffer) then the data is immediately > returned, improving batching. > * Poll is only armed once and reused, saving CPU cycles The latter is really a big deal, it saves a substantial amount of wait queue locking and manipulation. In general this looks good to me. I agree on allowing length of 0, we strictly don't need a length as that is implicit from the provided buffer anyway (and capped by that, ultimately). Nice cleanups leading into the real change too. Added some individual comments on select patches. -- Jens Axboe
