public inbox for [email protected]
 help / color / mirror / Atom feed
* [PATCHSET 0/3] Cleanup and improve sendmsg/recvmsg header handling
@ 2024-02-27 18:46 Jens Axboe
  2024-02-27 18:46 ` [PATCH 1/3] io_uring/net: unify how recvmsg and sendmsg copy in the msghdr Jens Axboe
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Jens Axboe @ 2024-02-27 18:46 UTC (permalink / raw)
  To: io-uring

Hi,

Been bugging me that I didn't like the v2 of the "improve the usercopy
for sendmsg/recvmsg" patch, so I re-did patch 1 here so that I could
do a prep patch (patch 2), and finally re-do the usercopy improvement
on top of that. Passes my testing, win is actually slightly larger
with this change (closer to 10%, so at least it didn't regress.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 5+ messages in thread
* [PATCHSET v2 0/3] Support for provided buffers for send
@ 2024-02-19 21:25 Jens Axboe
  2024-02-19 21:25 ` [PATCH 1/3] io_uring/net: unify how recvmsg and sendmsg copy in the msghdr Jens Axboe
  0 siblings, 1 reply; 5+ messages in thread
From: Jens Axboe @ 2024-02-19 21:25 UTC (permalink / raw)
  To: io-uring

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 36% improvement with this over manually dealing with sends. That's
a pretty big win on top of making the app simpler.

This also opens the door for multishot send requests, which is an
interesting future venue to pursue!

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 v1:

- Forgot that the sendmsg side uses the generic helper for this, whereas
  recvmsg rolls its own to deal with provided buffers. Unify them in patch
  1 instead.

 include/uapi/linux/io_uring.h |   1 +
 io_uring/io_uring.c           |   3 +-
 io_uring/net.c                | 309 +++++++++++++++++++---------------
 io_uring/opdef.c              |   2 +
 4 files changed, 175 insertions(+), 140 deletions(-)

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2024-02-27 18:48 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-02-27 18:46 [PATCHSET 0/3] Cleanup and improve sendmsg/recvmsg header handling Jens Axboe
2024-02-27 18:46 ` [PATCH 1/3] io_uring/net: unify how recvmsg and sendmsg copy in the msghdr Jens Axboe
2024-02-27 18:46 ` [PATCH 2/3] io_uring/net: move receive multishot out of the generic msghdr path Jens Axboe
2024-02-27 18:46 ` [PATCH 3/3] io_uring/net: improve the usercopy for sendmsg/recvmsg Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2024-02-19 21:25 [PATCHSET v2 0/3] Support for provided buffers for send Jens Axboe
2024-02-19 21:25 ` [PATCH 1/3] io_uring/net: unify how recvmsg and sendmsg copy in the msghdr Jens Axboe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox