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 1/8] udp: fixup csum for GSO receive slow path
Date: Thu, 25 Mar 2021 17:47:36 +0100	[thread overview]
Message-ID: <030bcf7a14ada8caa464bb33916e5abc19eab67c.camel@redhat.com> (raw)
In-Reply-To: <CA+FuTSepOe88N_jY+9F5gTu6ShzMa8rOZzi6CAsF+4k6iPeajw@mail.gmail.com>

On Thu, 2021-03-25 at 09:53 -0400, Willem de Bruijn wrote:
> On Thu, Mar 25, 2021 at 6:57 AM Paolo Abeni <pabeni@redhat.com> wrote:
> > AFAICS, it depends ;) From skbuff.h:
> > 
> >  *   skb->csum_level indicates the number of consecutive checksums found in
> >  *   the packet minus one that have been verified as CHECKSUM_UNNECESSARY.
> > 
> > if skb->csum_level > 0, the NIC validate additional headers. The intel
> > ixgbe driver use that for vxlan RX csum offload. Such field translates
> > into:
> > 
> >         NAPI_GRO_CB(skb)->csum_cnt
> > 
> > inside the GRO engine, and skb_gro_incr_csum_unnecessary takes care of
> > the updating it after validation.
> 
> True. I glanced over those cases.
> 
> More importantly, where exactly do these looped packets get converted
> from CHECKSUM_PARTIAL to CHECKSUM_NONE before this patch?

Very good question! It took a bit finding the exact place.

int __iptunnel_pull_header(struct sk_buff *skb, int hdr_len,
			   __be16 inner_proto, bool raw_proto, bool xnet)
{
	if (unlikely(!pskb_may_pull(skb, hdr_len)))
		return -ENOMEM;

	skb_pull_rcsum(skb, hdr_len);
        // here ^^^ via skb_pull_rcsum -> skb_postpull_rcsum() -> __skb_postpull_rcsum()

well, this is actually with _this_ patch applied: it does not change
the place where the ip_summed is set.

> > My understanding is that the following should be better:
> > 
> > static inline void udp_post_segment_fix_csum(struct sk_buff *skb)
> > {
> >         /* UDP-lite can't land here - no GRO */
> >         WARN_ON_ONCE(UDP_SKB_CB(skb)->partial_cov);
> > 
> >         /* UDP packets generated with UDP_SEGMENT and traversing:
> >          * UDP tunnel(xmit) -> veth (segmentation) -> veth (gro) -> UDP tunnel (rx)
> >          * land here with CHECKSUM_NONE. Instead of adding another check
> >          * in the tunnel fastpath, we can force valid csums here:
> >          * packets are locally generated and the GRO engine already validated
> >          * the csum.
> >          * Additionally fixup the UDP CB
> >          */
> >         UDP_SKB_CB(skb)->cscov = skb->len;
> >         if (skb->ip_summed == CHECKSUM_NONE && !skb->csum_valid)
> >                 skb->csum_valid = 1;
> > }
> > 
> > I'll use the above in v2.
> 
> Do I understand correctly that this avoids matching tunneled packets
> that arrive from the network with rx checksumming disabled, because
> __skb_gro_checksum_complete will have been called on the outer packet
> and have set skb->csum_valid?

Exactly. I did the test, and perf probes showed that.

> Yes, this just (1) identifying the packet as being of local source and
> then (2) setting csum_valid sounds great to me, thanks.

Will try to submit v2 soon, after some more testing.

Thanks for all the feedback!

Paolo


  reply	other threads:[~2021-03-25 16:48 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 [this message]
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
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=030bcf7a14ada8caa464bb33916e5abc19eab67c.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.