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 v2 1/8] udp: fixup csum for GSO receive slow path
Date: Mon, 29 Mar 2021 13:25:37 +0200	[thread overview]
Message-ID: <c7ee2326473578aa1600bf7c062f37c01e95550a.camel@redhat.com> (raw)
In-Reply-To: <CA+FuTSed_T6+QbdgEUCo2Qy39mH1AVRoPqFYvt_vkRiFxfW7ZA@mail.gmail.com>

On Fri, 2021-03-26 at 14:30 -0400, Willem de Bruijn wrote:
> On Thu, Mar 25, 2021 at 1:24 PM Paolo Abeni <pabeni@redhat.com> wrote:
> > When UDP packets generated locally by a socket with UDP_SEGMENT
> > traverse the following path:
> > 
> > UDP tunnel(xmit) -> veth (segmentation) -> veth (gro) ->
> >         UDP tunnel (rx) -> UDP socket (no UDP_GRO)
> > 
> > they are segmented as part of the rx socket receive operation, and
> > present a CHECKSUM_NONE after segmentation.
> 
> would be good to capture how this happens, as it was not immediately obvious.

The CHECKSUM_PARTIAL is propagated up to the UDP tunnel processing,
where we have:

	__iptunnel_pull_header() -> skb_pull_rcsum() ->
skb_postpull_rcsum() -> __skb_postpull_rcsum() and the latter do the
conversion.

> > Additionally the segmented packets UDP CB still refers to the original
> > GSO packet len. Overall that causes unexpected/wrong csum validation
> > errors later in the UDP receive path.
> > 
> > We could possibly address the issue with some additional checks and
> > csum mangling in the UDP tunnel code. Since the issue affects only
> > this UDP receive slow path, let's set a suitable csum status there.
> > 
> > v1 -> v2:
> >  - restrict the csum update to the packets strictly needing them
> >  - hopefully clarify the commit message and code comments
> > 
> > Signed-off-by: Paolo Abeni <pabeni@redhat.com>
> > +       if (skb->ip_summed == CHECKSUM_NONE && !skb->csum_valid)
> > +               skb->csum_valid = 1;
> 
> Not entirely obvious is that UDP packets arriving on a device with rx
> checksum offload off, i.e., with CHECKSUM_NONE, are not matched by
> this test.
> 
> I assume that such packets are not coalesced by the GRO layer in the
> first place. But I can't immediately spot the reason for it..

Packets with CHECKSUM_NONE are actually aggregated by the GRO engine. 

Their checksum is validated by:

udp4_gro_receive -> skb_gro_checksum_validate_zero_check()
	-> __skb_gro_checksum_validate -> __skb_gro_checksum_validate_complete() 

and skb->ip_summed is changed to CHECKSUM_UNNECESSARY by:

__skb_gro_checksum_validate -> skb_gro_incr_csum_unnecessary
	-> __skb_incr_checksum_unnecessary()

and finally to CHECKSUM_PARTIAL by:

udp4_gro_complete() -> udp_gro_complete() -> udp_gro_complete_segment()

Do you prefer I resubmit with some more comments, either in the commit
message or in the code?

Thanks

Paolo

side note: perf probe here is fooled by skb->ip_summed being a bitfield
and does not dump the real value. I had to look at skb-
>__pkt_type_offset[0] instead.


  reply	other threads:[~2021-03-29 11:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-25 17:23 [PATCH net-next v2 0/8] udp: GRO L4 improvements Paolo Abeni
2021-03-25 17:24 ` [PATCH net-next v2 1/8] udp: fixup csum for GSO receive slow path Paolo Abeni
2021-03-26 18:30   ` Willem de Bruijn
2021-03-29 11:25     ` Paolo Abeni [this message]
2021-03-29 12:28       ` Willem de Bruijn
2021-03-29 13:24         ` Paolo Abeni
2021-03-29 13:52           ` Willem de Bruijn
2021-03-29 15:00             ` Paolo Abeni
2021-03-29 15:24               ` Willem de Bruijn
2021-03-29 16:23                 ` Paolo Abeni
2021-03-29 22:37                   ` Willem de Bruijn
2021-03-25 17:24 ` [PATCH net-next v2 2/8] udp: skip L4 aggregation for UDP tunnel packets Paolo Abeni
2021-03-26 18:23   ` Willem de Bruijn
2021-03-25 17:24 ` [PATCH net-next v2 3/8] udp: properly complete L4 GRO over UDP tunnel packet Paolo Abeni
2021-03-26 17:51   ` Willem de Bruijn
2021-03-25 17:24 ` [PATCH net-next v2 4/8] udp: never accept GSO_FRAGLIST packets Paolo Abeni
2021-03-26 18:15   ` Willem de Bruijn
2021-03-29  8:11     ` Paolo Abeni
2021-03-29 12:31       ` Willem de Bruijn
2021-03-29 13:29         ` Paolo Abeni
2021-03-25 17:24 ` [PATCH net-next v2 5/8] vxlan: allow L4 GRO passthrough Paolo Abeni
2021-03-25 17:24 ` [PATCH net-next v2 6/8] geneve: allow UDP L4 GRO passthrou Paolo Abeni
2021-03-25 17:24 ` [PATCH net-next v2 7/8] bareudp: " Paolo Abeni
2021-03-25 17:24 ` [PATCH net-next v2 8/8] selftests: net: add UDP GRO forwarding self-tests 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=c7ee2326473578aa1600bf7c062f37c01e95550a.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.