• Jens Axboe's avatar
    io_uring/net: add provided buffer support for IORING_OP_SEND · ac5f71a3
    Jens Axboe authored
    It's pretty trivial to wire up provided buffer support for the send
    side, just like how it's done the receive side. This enables setting up
    a buffer ring that an application can use to push pending sends to,
    and then have a send pick a buffer from that ring.
    
    One of the challenges with async IO and networking sends is that you
    can get into reordering conditions if you have more than one inflight
    at the same time. Consider the following scenario where everything is
    fine:
    
    1) App queues sendA for socket1
    2) App queues sendB for socket1
    3) App does io_uring_submit()
    4) sendA is issued, completes successfully, posts CQE
    5) sendB is issued, completes successfully, posts CQE
    
    All is fine. Requests are always issued in-order, and both complete
    inline as most sends do.
    
    However, if we're flooding socket1 with sends, the following could
    also result from the same sequence:
    
    1) App queues sendA for socket1
    2) App queues sendB for socket1
    3) App does io_uring_submit()
    4) sendA is issued, socket1 is full, poll is armed for retry
    5) Space frees up in socket1, this triggers sendA retry via task_work
    6) sendB is issued, completes successfully, posts CQE
    7) sendA is retried, completes successfully, posts CQE
    
    Now we've sent sendB before sendA, which can make things unhappy. If
    both sendA and sendB had been using provided buffers, then it would look
    as follows instead:
    
    1) App queues dataA for sendA, queues sendA for socket1
    2) App queues dataB for sendB queues sendB for socket1
    3) App does io_uring_submit()
    4) sendA is issued, socket1 is full, poll is armed for retry
    5) Space frees up in socket1, this triggers sendA retry via task_work
    6) sendB is issued, picks first buffer (dataA), completes successfully,
       posts CQE (which says "I sent dataA")
    7) sendA is retried, picks first buffer (dataB), completes successfully,
       posts CQE (which says "I sent dataB")
    
    Now we've sent the data in order, and everybody is happy.
    
    It's worth noting that this also opens the door for supporting multishot
    sends, as provided buffers would be a prerequisite for that. Those can
    trigger either when new buffers are added to the outgoing ring, or (if
    stalled due to lack of space) when space frees up in the socket.
    Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
    ac5f71a3
opdef.c 15.2 KB