On Thu, 2022-07-14 at 07:46 +0000, David Laight wrote: > From: Dylan Yudaken > > Sent: 13 July 2022 09:23 > > > > Similar to multishot recv, this will require provided buffers to be > > used. However recvmsg is much more complex than recv as it has > > multiple > > outputs. Specifically flags, name, and control messages. > ... > > Why is this any different from adding several 'recvmsg' requests > into the request ring? > > IIUC the requests are all processed sequentially by a single thread. > In practice it is mostly the same for UDP (apart from userspace having to predict how many recvmsg requests it should add). That approach would also have a slight ordering race, which probably is not a problem for protocols that don't guarantee ordering, but might be annoying. For stream like TCP it would not be possible due to the ordering issues (completions of separate SQEs have no guaranteed ordering). You would have to link the SQE's to preserve ordering, but then you would still have to wait for a batch to complete before submitting a new batch. Apart from those practical reasons, performance wise it is better for a few reasons * userspace doesn't have to submit new requests * the io_uring knows it's multishot, so doesn't teardown the poll each time * io_uring can allocate the request and associated async data only once and reuse it Regards, Dylan > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, > MK1 1PT, UK > Registration No: 1397386 (Wales) >
