All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Paolo Abeni <pabeni@redhat.com>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
	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 3/8] udp: properly complete L4 GRO over UDP tunnel packet
Date: Tue, 23 Mar 2021 22:13:10 -0400	[thread overview]
Message-ID: <CA+FuTSd1R1mU+yP3g=8hzdQXKjGXY=sYvozj10+25-kzTSwWfA@mail.gmail.com> (raw)
In-Reply-To: <6d5fae11c4eecda3f59f9491426834fce8c37f7e.camel@redhat.com>

On Mon, Mar 22, 2021 at 1:00 PM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On Mon, 2021-03-22 at 09:30 -0400, Willem de Bruijn wrote:
> > On Sun, Mar 21, 2021 at 1:01 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > > After the previous patch the stack can do L4 UDP aggregation
> > > on top of an UDP tunnel.
> > >
> > > The current GRO complete code tries frag based aggregation first;
> > > in the above scenario will generate corrupted frames.
> > >
> > > We need to try first UDP tunnel based aggregation, if the GRO
> > > packet requires that. We can use time GRO 'encap_mark' field
> > > to track the need GRO complete action. If encap_mark is set,
> > > skip the frag_list aggregation.
> > >
> > > On tunnel encap GRO complete clear such field, so that an inner
> > > frag_list GRO complete could take action.
> > >
> > > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > > ---
> > >  net/ipv4/udp_offload.c | 8 +++++++-
> > >  net/ipv6/udp_offload.c | 3 ++-
> > >  2 files changed, 9 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
> > > index 25134a3548e99..54e06b88af69a 100644
> > > --- a/net/ipv4/udp_offload.c
> > > +++ b/net/ipv4/udp_offload.c
> > > @@ -642,6 +642,11 @@ int udp_gro_complete(struct sk_buff *skb, int nhoff,
> > >                 skb_shinfo(skb)->gso_type = uh->check ? SKB_GSO_UDP_TUNNEL_CSUM
> > >                                         : SKB_GSO_UDP_TUNNEL;
> > >
> > > +               /* clear the encap mark, so that inner frag_list gro_complete
> > > +                * can take place
> > > +                */
> > > +               NAPI_GRO_CB(skb)->encap_mark = 0;
> > > +
> > >                 /* Set encapsulation before calling into inner gro_complete()
> > >                  * functions to make them set up the inner offsets.
> > >                  */
> > > @@ -665,7 +670,8 @@ INDIRECT_CALLABLE_SCOPE int udp4_gro_complete(struct sk_buff *skb, int nhoff)
> > >         const struct iphdr *iph = ip_hdr(skb);
> > >         struct udphdr *uh = (struct udphdr *)(skb->data + nhoff);
> > >
> > > -       if (NAPI_GRO_CB(skb)->is_flist) {
> > > +       /* do fraglist only if there is no outer UDP encap (or we already processed it) */
> > > +       if (NAPI_GRO_CB(skb)->is_flist && !NAPI_GRO_CB(skb)->encap_mark) {
> >
> > Sorry, I don't follow. I thought the point was to avoid fraglist if an
> > outer udp tunnel header is present. But the above code clears the mark
> > and allows entering the fraglist branch exactly when such a header is
> > encountered?
>
> The relevant UDP packet has gone through:
>
> [l2/l3 GRO] -> udp_gro_receive  -> udp_sk(sk)->gro_receive -> [some
> more GRO layers] -> udp_gro_receive (again)
>
> The first udp_gro_receive set NAPI_GRO_CB(skb)->encap_mark, the
> latter udp_gro_receive set NAPI_GRO_CB(skb)->is_flist.
>
> Then, at GRO complete time:
>
> [l2/l3 GRO] -> udp{4,6}_gro_complete -> udp_sk(sk)->gro_complete ->
> [more GRO layers] -> udp{4,6}_gro_complete (again).
>
> In the first udp{4,6}_gro_complete invocation 'encap_mark' is 1, so
> with this patch we do the 'udp_sk(sk)->gro_complete' path. In the
> second udp{4,6}_gro_complete invocation 'encap_mark' has been cleared
> (by udp_gro_complete), so we do the SKB_GSO_FRAGLIST completion.
>
> In case SKB_GSO_FRAGLIST with no UDP tunnel, 'encap_mark' is 0 and we
> do the SKB_GSO_FRAGLIST completion.
>
> Another alternative, possibly more readable, would be avoid clearing
> 'encap_mark' in udp_gro_complete() and replacing the above check with:
>
>         if (NAPI_GRO_CB(skb)->is_flist &&
>             (!NAPI_GRO_CB(skb)->encap_mark ||
>              (NAPI_GRO_CB(skb)->encap_mark && skb->encapsulation))) {
>
> I opted otherwise to simplify the conditional expression.
>
> Please let me know if the above is somewhat more clear and if you have
> preferecens between the two options.

Got it now, thanks. Yes, this patch makes sense.

When the GRO layer has built a GSO packet with both inner UDP
(GSO_UDP_L4) and UDP tunnel header (GSO_UDP_TUNNEL), then on
completion udp{4,6}_gro_complete will be called twice. This function
will enter its is_flist branch immediately, even though that is only
correct on the second call, as GSO_FRAGLIST is only relevant for the
inner packet. Skip this while encap_mark == 1, identifying processing
of the outer tunnel header. Clear the field to enter the path on the next
round, for the inner header.

This is subject to only supporting a single layer of encap, but that
is indeed the current state afaik.

  reply	other threads:[~2021-03-24  2:14 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 [this message]
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
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='CA+FuTSd1R1mU+yP3g=8hzdQXKjGXY=sYvozj10+25-kzTSwWfA@mail.gmail.com' \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=alobakin@pm.me \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=steffen.klassert@secunet.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.