On Mon, Feb 26, 2024 at 1:38 PM Jens Axboe <axboe@xxxxxxxxx> wrote: > > On 2/26/24 3:47 AM, Dylan Yudaken wrote: > > On Sun, Feb 25, 2024 at 12:46?AM Jens Axboe <axboe@xxxxxxxxx> wrote: > >> > >> This works very much like the receive side, except for sends. The idea > >> is that an application can fill outgoing buffers in a provided buffer > >> group, and then arm a single send that will service them all. For now > >> this variant just terminates when we are out of buffers to send, and > >> hence the application needs to re-arm it if IORING_CQE_F_MORE isn't > >> set, as per usual for multishot requests. > >> > > > > This feels to me a lot like just using OP_SEND with MSG_WAITALL as > > described, unless I'm missing something? > > How so? MSG_WAITALL is "send X amount of data, and if it's a short send, > try again" where multishot is "send data from this buffer group, and > keep sending data until it's empty". Hence it's the mirror of multishot > on the receive side. Unless I'm misunderstanding you somehow, not sure > it'd be smart to add special meaning to MSG_WAITALL with provided > buffers. > _If_ you have the data upfront these are very similar, and only differ in that the multishot approach will give you more granular progress updates. My point was that this might not be a valuable API to people for only this use case. You do make a good point about MSG_WAITALL though - multishot send doesn't really make sense to me without MSG_WAITALL semantics. I cannot imagine a useful use case where the first buffer being partially sent will still want the second buffer sent. > > I actually could imagine it being useful for the previous patches' use > > case of queuing up sends and keeping ordering, > > and I think the API is more obvious (rather than the second CQE > > sending the first CQE's data). So maybe it's worth only > > keeping one approach? > > And here you totally lost me :-) I am suggesting here that you don't really need to support buffer lists on send without multishot. It's a slightly confusing API (to me) that you queue PushBuffer(A), Send(A), PushBuffer(B), Send(B) and get back Res(B), Res(A) which are in fact in order A->B. Instead you could queue up PushBuffer(A), Send(Multishot), PushBuffer(B), and get back Res(Multishot), Res(Multishot) which are in order A -> B. The downside here is that userspace has to handle requeueing the SQE if A completes before B is pushed. I leave it to you if that is not desirable. I can see arguments for both sides.
