[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADvbK_en7mePKdmMaLr9V8hTdmjf2bSVpSrid2CjharJtvD6YQ@mail.gmail.com>
Date: Fri, 9 Oct 2020 09:48:45 +0800
From: Xin Long <lucien.xin@...il.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: network dev <netdev@...r.kernel.org>, linux-sctp@...r.kernel.org,
Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
Neil Horman <nhorman@...driver.com>,
Michael Tuexen <tuexen@...muenster.de>,
David Miller <davem@...emloft.net>
Subject: Re: [PATCHv2 net-next 02/17] udp6: move the mss check after udp gso
tunnel processing
On Thu, Oct 8, 2020 at 8:45 PM Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
>
> On Thu, Oct 8, 2020 at 5:48 AM Xin Long <lucien.xin@...il.com> wrote:
> >
> > For some protocol's gso, like SCTP, it's using GSO_BY_FRAGS for
> > gso_size. When using UDP to encapsulate its packet, it will
> > return error in udp6_ufo_fragment() as skb->len < gso_size,
> > and it will never go to the gso tunnel processing.
> >
> > So we should move this check after udp gso tunnel processing,
> > the same as udp4_ufo_fragment() does. While at it, also tidy
> > the variables up.
>
> Please don't mix a new feature and code cleanup.
Hi, Willem,
Tidying up variables are not worth a single patch, that's what I was
thinking. I can leave the variables as it is if you wish in this patch.
>
> This patch changes almost every line of the function due to
> indentation changes. But the only relevant part is
>
> "
> mss = skb_shinfo(skb)->gso_size;
> if (unlikely(skb->len <= mss))
> goto out;
>
> if (skb->encapsulation && skb_shinfo(skb)->gso_type &
> (SKB_GSO_UDP_TUNNEL|SKB_GSO_UDP_TUNNEL_CSUM))
> segs = skb_udp_tunnel_segment(skb, features, true);
> else {
> /* irrelevant here */
> }
>
> out:
> return segs;
> }
> "
>
> Is it a sufficient change to just skip the mss check if mss == GSO_BY_FRAGS?
It is sufficient.
But I think we'd better keep the code here consistent with ipv4's if
there's no other reason to do 'skb->len <= mss' check at the first.
We can go with if-else as you showed above now, then do a cleanup in
the future. What do you think?
Powered by blists - more mailing lists