From: Simon Horman <horms@kernel.org>
To: Ronak Doshi <ronak.doshi@broadcom.com>
Cc: netdev@vger.kernel.org, Guolin Yang <guolin.yang@broadcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@broadcom.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net v4] vmxnet3: correctly report gso type for UDP tunnels
Date: Tue, 3 Jun 2025 08:23:08 +0100 [thread overview]
Message-ID: <20250603072308.GW1484967@horms.kernel.org> (raw)
In-Reply-To: <20250530152701.70354-1-ronak.doshi@broadcom.com>
On Fri, May 30, 2025 at 03:27:00PM +0000, Ronak Doshi wrote:
> Commit 3d010c8031e3 ("udp: do not accept non-tunnel GSO skbs landing
> in a tunnel") added checks in linux stack to not accept non-tunnel
> GRO packets landing in a tunnel. This exposed an issue in vmxnet3
> which was not correctly reporting GRO packets for tunnel packets.
>
> This patch fixes this issue by setting correct GSO type for the
> tunnel packets.
>
> Currently, vmxnet3 does not support reporting inner fields for LRO
> tunnel packets. The issue is not seen for egress drivers that do not
> use skb inner fields. The workaround is to enable tnl-segmentation
> offload on the egress interfaces if the driver supports it. This
> problem pre-exists this patch fix and can be addressed as a separate
> future patch.
>
> Fixes: dacce2be3312 ("vmxnet3: add geneve and vxlan tunnel offload support")
> Signed-off-by: Ronak Doshi <ronak.doshi@broadcom.com>
> Acked-by: Guolin Yang <guolin.yang@broadcom.com>
>
> Changes v1-->v2:
> Do not set encapsulation bit as inner fields are not updated
> Changes v2-->v3:
> Update the commit message explaining the next steps to address
> segmentation issues that pre-exists this patch fix.
> Changes v3->v4:
> Update the commit message to clarify the workaround.
> ---
> drivers/net/vmxnet3/vmxnet3_drv.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
> index c676979c7ab9..287b7c20c0d6 100644
> --- a/drivers/net/vmxnet3/vmxnet3_drv.c
> +++ b/drivers/net/vmxnet3/vmxnet3_drv.c
> @@ -1568,6 +1568,30 @@ vmxnet3_get_hdr_len(struct vmxnet3_adapter *adapter, struct sk_buff *skb,
> return (hlen + (hdr.tcp->doff << 2));
> }
>
> +static void
> +vmxnet3_lro_tunnel(struct sk_buff *skb, __be16 ip_proto)
> +{
> + struct udphdr *uh = NULL;
> +
> + if (ip_proto == htons(ETH_P_IP)) {
> + struct iphdr *iph = (struct iphdr *)skb->data;
> +
> + if (iph->protocol == IPPROTO_UDP)
> + uh = (struct udphdr *)(iph + 1);
> + } else {
> + struct ipv6hdr *iph = (struct ipv6hdr *)skb->data;
> +
> + if (iph->nexthdr == IPPROTO_UDP)
> + uh = (struct udphdr *)(iph + 1);
> + }
Hi Ronak,
Possibly a naive question, but does skb->data always contain an iphdr
or ipv6hdr? Or perhaps more to the point, is it safe to assume IPv6
is ip_proto is not ETH_P_IP?
> + if (uh) {
> + if (uh->check)
> + skb_shinfo(skb)->gso_type |= SKB_GSO_UDP_TUNNEL_CSUM;
> + else
> + skb_shinfo(skb)->gso_type |= SKB_GSO_UDP_TUNNEL;
> + }
> +}
> +
> static int
> vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
> struct vmxnet3_adapter *adapter, int quota)
> @@ -1881,6 +1905,8 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
> if (segCnt != 0 && mss != 0) {
> skb_shinfo(skb)->gso_type = rcd->v4 ?
> SKB_GSO_TCPV4 : SKB_GSO_TCPV6;
> + if (encap_lro)
> + vmxnet3_lro_tunnel(skb, skb->protocol);
> skb_shinfo(skb)->gso_size = mss;
> skb_shinfo(skb)->gso_segs = segCnt;
> } else if ((segCnt != 0 || skb->len > mtu) && !encap_lro) {
> --
> 2.45.2
>
>
next prev parent reply other threads:[~2025-06-03 7:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-30 15:27 [PATCH net v4] vmxnet3: correctly report gso type for UDP tunnels Ronak Doshi
2025-06-03 7:23 ` Simon Horman [this message]
2025-06-03 9:27 ` Paolo Abeni
2025-06-03 10:10 ` patchwork-bot+netdevbpf
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=20250603072308.GW1484967@horms.kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=guolin.yang@broadcom.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=ronak.doshi@broadcom.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.