IO-Uring Archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: io-uring@vger.kernel.org
Cc: asml.silence@gmail.com, dyudaken@gmail.com
Subject: [PATCHSET v4 0/9] Support for provided buffers for send
Date: Mon, 26 Feb 2024 12:21:12 -0700	[thread overview]
Message-ID: <20240226192458.396832-1-axboe@kernel.dk> (raw)

Hi,

We never supported provided buffers for sends, because it didn't seem
to make a lot of sense. But it actually does make a lot of sense! If
an app is receiving data, doing something with it, and then sending
either the same or another buffer out based on that, then if we use
provided buffers for sends we can guarantee that the sends are
serialized. This is because provided buffer rings are FIFO ordered,
as it's a ring buffer, and hence it doesn't really matter if you
have more than one send inflight.

This provides a nice efficiency win, but more importantly, it reduces
the complexity in the application as it no longer needs to track a
potential backlog of sends. The app just sets up a send based buffer
ring, exactly like it does for incoming data. And that's it, no more
dealing with serialized sends.

In some testing with proxy [1], in basic shuffling of packets I see a
68% improvement with this over manually dealing with serializing sends.
That's a pretty big win on top of making the app simpler. Using
multishot further brings a nice improvement on top, about 10% extra on
top.

You can also find the patches here:

https://git.kernel.dk/cgit/linux/log/?h=io_uring-send-queue

[1] https://git.kernel.dk/cgit/liburing/tree/examples/proxy.c

Changes since v3:

- Drop MSG_MORE patch, separate thing anyway. Moved the flags hunk into
  the respective send/sendmsg patches, where they actually belonged.
- Rename IORING_FEAT_SEND_BUFS to IORING_FEAT_SEND_BUF_SELECT
- Enable MSG_WAITALL for send multishot. If set, then we retry via
  poll, if not set, we terminate the multishot sequence. This also
  fixes send multishot with short send in general.
- Add other networking related patch for recv/recvmsg multishot,
  managing IORING_CQE_F_MORE better rather than always needing to hit
  -ENOBUFS to terminate.

-- 
Jens Axboe


             reply	other threads:[~2024-02-26 19:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-26 19:21 Jens Axboe [this message]
2024-02-26 19:21 ` [PATCH 1/9] net: remove {revc,send}msg_copy_msghdr() from exports Jens Axboe
2024-02-26 19:21 ` [PATCH 2/9] io_uring/net: add provided buffer support for IORING_OP_SEND Jens Axboe
2024-02-26 19:21 ` [PATCH 3/9] io_uring/net: add provided buffer support for IORING_OP_SENDMSG Jens Axboe
2024-02-26 19:21 ` [PATCH 4/9] io_uring/kbuf: flag request if buffer pool is empty after buffer pick Jens Axboe
2024-02-26 19:21 ` [PATCH 5/9] io_uring/net: avoid redundant -ENOBUFS on recv multishot retry Jens Axboe
2024-02-26 19:21 ` [PATCH 6/9] io_uring/net: move recv/recvmsg flags out of retry loop Jens Axboe
2024-02-26 19:21 ` [PATCH 7/9] io_uring/net: add generic multishot retry helper Jens Axboe
2024-02-26 19:21 ` [PATCH 8/9] io_uring/net: support multishot for send Jens Axboe
2024-02-26 19:21 ` [PATCH 9/9] io_uring/net: support multishot for sendmsg Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240226192458.396832-1-axboe@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=asml.silence@gmail.com \
    --cc=dyudaken@gmail.com \
    --cc=io-uring@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).