public inbox for [email protected]
 help / color / mirror / Atom feed
From: David Ahern <[email protected]>
To: Pavel Begunkov <[email protected]>,
	[email protected], [email protected]
Cc: Jens Axboe <[email protected]>,
	"David S . Miller" <[email protected]>,
	Jakub Kicinski <[email protected]>,
	Eric Dumazet <[email protected]>,
	Willem de Bruijn <[email protected]>
Subject: Re: [RFC 0/6] implement io_uring notification (ubuf_info) stacking
Date: Sat, 13 Apr 2024 11:17:15 -0600	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 4/12/24 6:55 AM, Pavel Begunkov wrote:
> io_uring allocates a ubuf_info per zerocopy send request, it's convenient
> for the userspace but with how things are it means that every time the 
> TCP stack has to allocate a new skb instead of amending into a previous
> one. Unless sends are big enough, there will be lots of small skbs
> straining the stack and dipping performance.

The ubuf_info forces TCP segmentation at less than MTU boundaries which
kills performance with small message sizes as TCP is forced to send
small packets. This is an interesting solution to allow the byte stream
to flow yet maintain the segmentation boundaries for callbacks.

> 
> The patchset implements notification, i.e. an io_uring's ubuf_info
> extension, stacking. It tries to link ubuf_info's into a list, and
> the entire link will be put down together once all references are
> gone.
> 
> Testing with liburing/examples/send-zerocopy and another custom made
> tool, with 4K bytes per send it improves performance ~6 times and
> levels it with MSG_ZEROCOPY. Without the patchset it requires much
> larger sends to utilise all potential.
> 
> bytes  | before | after (Kqps)  
> 100    | 283    | 936
> 1200   | 195    | 1023
> 4000   | 193    | 1386
> 8000   | 154    | 1058
> 
> Pavel Begunkov (6):
>   net: extend ubuf_info callback to ops structure
>   net: add callback for setting a ubuf_info to skb
>   io_uring/notif: refactor io_tx_ubuf_complete()
>   io_uring/notif: remove ctx var from io_notif_tw_complete
>   io_uring/notif: simplify io_notif_flush()
>   io_uring/notif: implement notification stacking
> 
>  drivers/net/tap.c      |  2 +-
>  drivers/net/tun.c      |  2 +-
>  drivers/vhost/net.c    |  8 +++-
>  include/linux/skbuff.h | 21 ++++++----
>  io_uring/notif.c       | 91 +++++++++++++++++++++++++++++++++++-------
>  io_uring/notif.h       | 13 +++---
>  net/core/skbuff.c      | 37 +++++++++++------
>  7 files changed, 129 insertions(+), 45 deletions(-)
> 


  parent reply	other threads:[~2024-04-13 17:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-12 12:55 [RFC 0/6] implement io_uring notification (ubuf_info) stacking Pavel Begunkov
2024-04-12 12:55 ` [RFC 1/6] net: extend ubuf_info callback to ops structure Pavel Begunkov
2024-04-13 17:17   ` David Ahern
2024-04-14 17:07   ` Willem de Bruijn
2024-04-15  0:07     ` Pavel Begunkov
2024-04-15 15:06       ` Willem de Bruijn
2024-04-15 18:55         ` Pavel Begunkov
2024-04-15 19:01           ` Willem de Bruijn
2024-04-16 14:50       ` David Ahern
2024-04-16 15:31         ` Pavel Begunkov
2024-04-12 12:55 ` [RFC 2/6] net: add callback for setting a ubuf_info to skb Pavel Begunkov
2024-04-13 17:18   ` David Ahern
2024-04-12 12:55 ` [RFC 3/6] io_uring/notif: refactor io_tx_ubuf_complete() Pavel Begunkov
2024-04-12 12:55 ` [RFC 4/6] io_uring/notif: remove ctx var from io_notif_tw_complete Pavel Begunkov
2024-04-12 12:55 ` [RFC 5/6] io_uring/notif: simplify io_notif_flush() Pavel Begunkov
2024-04-12 12:55 ` [RFC 6/6] io_uring/notif: implement notification stacking Pavel Begunkov
2024-04-14 17:10   ` Willem de Bruijn
2024-04-14 23:55     ` Pavel Begunkov
2024-04-15 15:15       ` Willem de Bruijn
2024-04-15 18:51         ` Pavel Begunkov
2024-04-15 19:02           ` Willem de Bruijn
2024-04-12 13:44 ` [RFC 0/6] implement io_uring notification (ubuf_info) stacking Jens Axboe
2024-04-12 14:52 ` Jens Axboe
2024-04-13 17:17 ` David Ahern [this message]
2024-04-15  0:08   ` Pavel Begunkov

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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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