public inbox for [email protected]
 help / color / mirror / Atom feed
From: Victor Stewart <[email protected]>
To: Pavel Begunkov <[email protected]>
Cc: [email protected]
Subject: Re: allowing msg_name and msg_control
Date: Sat, 7 Nov 2020 17:12:25 +0000	[thread overview]
Message-ID: <CAM1kxwhUve61-6L=Vb40xXWip8m578ZYO-Mpb6Ys9x5aiK6LPg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>

On Sat, Nov 7, 2020 at 4:24 PM Pavel Begunkov <[email protected]> wrote:
>
> On 07/11/2020 14:22, Victor Stewart wrote:
> > RE Jen's proposed patch here
> > https://lore.kernel.org/io-uring/[email protected]/
>
> Hmm, I haven't seen this thread, thanks for bringing it up
>
> >
> > and RE what Stefan just mentioned in the "[PATCH 5.11] io_uring: don't
> > take fs for recvmsg/sendmsg" thread a few minutes ago... "Can't we
> > better remove these checks and allow msg_control? For me it's a
> > limitation that I would like to be removed."... which I coincidentally
> > just read when coming on here to advocate the same.
> >
> > I also require this for a few vital performance use cases:
> >
> > 1) GSO (UDP_SEGMENT to sendmsg)
> > 2) GRO (UDP_GRO from recvmsg)
>
> Don't know these you listed, may read about them later, but wouldn't [1]
> be enough? I was told it's queued up.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/net/socket.c?id=583bbf0624dfd8fc45f1049be1d4980be59451ff
>

Hadn't seen [1], but yes as long as the same were also implemented for
__sys_sendmsg_sock(). Queued up for.. 5.11?

UDP_SEGMENT allows you to sendmsg a UDP message payload up to ~64K
(Max IP Packet size - IPv4(6) header size - UDP header size).. in
order to obey the existing network stack expectations/limitations).
That payload is actually a sequence of DPLPMTUD sized packets (because
MTU size is restricted by / variable per path to each client). That
DPLPMTUD size is provided by the UDP_SEGMENT value, with the last
packet allowed to be a smaller size.

So you can send ~40 UDP messages but only pay the cost of network
stack traversal once. Then the segmentation occurs in the NIC (or in
the kernel with the NIC has no UDP GSO support, but most all do).

There's also a pacing patch in the works for UDP GSO sends:
https://lwn.net/Articles/822726/

Then UDP_GRO is the exact inverse, so when you recvmsg() you receive a
giant payload with the individual packet size notified via the UDP_GRO
value, then self segment.

These mimic the same optimizations available without configuration for
TCP streams.

Willem discusses all in the below paper (and there's a talk on youtube).
http://vger.kernel.org/lpc_net2018_talks/willemdebruijn-lpc2018-udpgso-paper-DRAFT-1.pdf

oh and sorry the title of this should have been sans msg_name.

> >
> > GSO and GRO are super important for QUIC servers... essentially
> > bringing a 3-4x performance improvement that brings them in line with
> > TCP efficiency.
> >
> > Would also allow the usage of...
> >
> > 3) MSG_ZEROCOPY (to receive the sock_extended_err from recvmsg)
> >
> > it's only a single digit % performance gain for large sends (but a
> > minor crutch until we get registered buffer sendmsg / recvmsg, which I
> > plan on implementing).

and i just began work on fixed versions of sendmsg / recvmsg. So i'll
distribute that patch for initial review probably this week. Should be
fairly trivial given the work exists for read/write.

> >
> > So if there's an agreed upon plan on action I can take charge of all
> > the work and get this done ASAP.
> >
> > #Victor
> >
>
> --
> Pavel Begunkov

  reply	other threads:[~2020-11-07 17:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-07 14:22 allowing msg_name and msg_control Victor Stewart
2020-11-07 16:21 ` Pavel Begunkov
2020-11-07 17:12   ` Victor Stewart [this message]
2020-11-07 20:15     ` 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 \
    --in-reply-to='CAM1kxwhUve61-6L=Vb40xXWip8m578ZYO-Mpb6Ys9x5aiK6LPg@mail.gmail.com' \
    [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