All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Network Development <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Steffen Klassert <steffen.klassert@secunet.com>,
	Alexander Lobakin <alobakin@pm.me>
Subject: Re: [PATCH net-next 4/8] udp: never accept GSO_FRAGLIST packets
Date: Wed, 24 Mar 2021 19:59:21 +0100	[thread overview]
Message-ID: <73664dd000dcbb432358a6559acbbf6b21d64150.camel@redhat.com> (raw)
In-Reply-To: <CA+FuTSfhU9ng6DuC7W6D8=OTk=5SJpqdz+xrQ12GYg4VtrdDZA@mail.gmail.com>

On Tue, 2021-03-23 at 22:21 -0400, Willem de Bruijn wrote:
> On Mon, Mar 22, 2021 at 1:12 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > On Mon, 2021-03-22 at 09:42 -0400, Willem de Bruijn wrote:
> > > On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > > > Currently the UDP protocol delivers GSO_FRAGLIST packets to
> > > > the sockets without the expected segmentation.
> > > > 
> > > > This change addresses the issue introducing and maintaining
> > > > a per socket bitmask of GSO types requiring segmentation.
> > > > Enabling GSO removes SKB_GSO_UDP_L4 from such mask, while
> > > > GSO_FRAGLIST packets are never accepted
> > > > 
> > > > Note: this also updates the 'unused' field size to really
> > > > fit the otherwise existing hole. It's size become incorrect
> > > > after commit bec1f6f69736 ("udp: generate gso with UDP_SEGMENT").
> > > > 
> > > > Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
> > > > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > > > ---
> > > >  include/linux/udp.h | 10 ++++++----
> > > >  net/ipv4/udp.c      | 12 +++++++++++-
> > > >  2 files changed, 17 insertions(+), 5 deletions(-)
> > > > 
> > > >         /*
> > > >          * Following member retains the information to create a UDP header
> > > >          * when the socket is uncorked.
> > > > @@ -68,7 +68,10 @@ struct udp_sock {
> > > >  #define UDPLITE_SEND_CC  0x2           /* set via udplite setsockopt         */
> > > >  #define UDPLITE_RECV_CC  0x4           /* set via udplite setsocktopt        */
> > > >         __u8             pcflag;        /* marks socket as UDP-Lite if > 0    */
> > > > -       __u8             unused[3];
> > > > +       __u8             unused[1];
> > > > +       unsigned int     unexpected_gso;/* GSO types this socket can't accept,
> > > > +                                        * any of SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST
> > > > +                                        */
> > > 
> > > An extra unsigned int for this seems overkill.
> > 
> > Should be more clear after the next patch.
> > 
> > Using an explicit 'acceptable GSO types' field makes the patch 5/8
> > quite simple.
> > 
> > After this patch the 'udp_sock' struct size remains unchanged and even
> > the number of 'udp_sock' cachelines touched for every packet is
> > unchanged.
> 
> But there is opportunity cost, of course. Next time we need to add
> something to the struct, we will add a new cacheline.
> 
> A 32-bit field for just 2 bits, where 1 already exists does seem like overkill.
> 
> More importantly, I just think it's less obvious code than a pair of fields
> 
>   accepts_udp_l4:1,
>   accepts_udp_fraglist:1,
> 
> Local sockets can only accept the first, as there does not exist an
> interface to pass along the multiple frag sizes that a frag_list based
> approach might have.
> 
> Sockets with encap_rcv != NULL may opt-in to being able to handle either.
> 
> I think explicit code will be more maintainable. 

ok

> At the cost of
> perhaps two branches instead of one, admittedly. But that seems
> premature optimization.

well, if it don't hurt too much your eyes, something along the
following could save udp_sock space and code branches:

    rejects_udp_l4_fraglist:2;

#define SKB_GSO_UDP_L4_SHIFT (NETIF_F_GSO_UDP_L4_BIT - NETIF_F_GSO_SHIFT)
 static inline bool udp_unexpected_gso(struct sock *sk, struct sk_buff *skb)
 {
	BUILD_BUG_ON(1 << SKB_GSO_UDP_L4_SHIFT != SKB_GSO_UDP_L4);
	BUILD_BUG_ON(1 << (SKB_GSO_UDP_L4_SHIFT + 1) != SKB_GSO_FRAGLIST);
 	return skb_is_gso(skb) && skb_shinfo(skb)->gso_type &
		(udp_sk(sk)->rejects_udp_l4_fraglist << SKB_GSO_UDP_L4_SHIFT);
 }

(not sure if /me runs/hides ;)

/P




  reply	other threads:[~2021-03-24 19:00 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-21 17:01 [PATCH net-next 0/8] udp: GRO L4 improvements Paolo Abeni
2021-03-21 17:01 ` [PATCH net-next 1/8] udp: fixup csum for GSO receive slow path Paolo Abeni
2021-03-22 13:18   ` Willem de Bruijn
2021-03-22 16:34     ` Paolo Abeni
2021-03-24  1:45       ` Willem de Bruijn
2021-03-24  1:49         ` Willem de Bruijn
2021-03-24 14:37         ` Paolo Abeni
2021-03-24 22:36           ` Willem de Bruijn
2021-03-25 10:56             ` Paolo Abeni
2021-03-25 13:53               ` Willem de Bruijn
2021-03-25 16:47                 ` Paolo Abeni
2021-03-21 17:01 ` [PATCH net-next 2/8] udp: skip fwd/list GRO for tunnel packets Paolo Abeni
2021-03-22 13:24   ` Willem de Bruijn
2021-03-22 16:41     ` Paolo Abeni
2021-03-24  1:54       ` Willem de Bruijn
2021-03-24 14:50         ` ! Paolo Abeni
2021-03-24 22:45           ` ! Willem de Bruijn
2021-03-21 17:01 ` [PATCH net-next 3/8] udp: properly complete L4 GRO over UDP tunnel packet Paolo Abeni
2021-03-22 13:30   ` Willem de Bruijn
2021-03-22 16:59     ` Paolo Abeni
2021-03-24  2:13       ` Willem de Bruijn
2021-03-21 17:01 ` [PATCH net-next 4/8] udp: never accept GSO_FRAGLIST packets Paolo Abeni
2021-03-22 13:42   ` Willem de Bruijn
2021-03-22 17:09     ` Paolo Abeni
2021-03-24  2:21       ` Willem de Bruijn
2021-03-24 18:59         ` Paolo Abeni [this message]
2021-03-24 22:12           ` Willem de Bruijn
2021-03-25 11:50             ` Paolo Abeni
2021-03-21 17:01 ` [PATCH net-next 5/8] vxlan: allow L4 GRO passthrou Paolo Abeni
2021-03-21 17:01 ` [PATCH net-next 6/8] geneve: allow UDP " Paolo Abeni
2021-03-21 17:01 ` [PATCH net-next 7/8] bareudp: " Paolo Abeni
2021-03-21 17:01 ` [PATCH net-next 8/8] selftests: net: add UDP GRO forwarding self-tests Paolo Abeni
2021-03-22 13:44   ` Willem de Bruijn
2021-03-22 17:18     ` Paolo Abeni
2021-03-23 17:12     ` Paolo Abeni

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=73664dd000dcbb432358a6559acbbf6b21d64150.camel@redhat.com \
    --to=pabeni@redhat.com \
    --cc=alobakin@pm.me \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    --cc=willemdebruijn.kernel@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.