Thread (11 messages) 11 messages, 3 authors, 2025-05-30

Re: [PATCH net] vmxnet3: correctly report gso type for UDP tunnels

From: Paolo Abeni <pabeni@redhat.com>
Date: 2025-05-19 07:30:04
Also in: lkml

On 5/15/25 4:02 PM, Jakub Kicinski wrote:
On Tue, 13 May 2025 21:05:02 +0000 Ronak Doshi wrote:
quoted
+				skb->encapsulation = 1;
 			}
 			WARN_ON_ONCE(!(gdesc->rcd.tcp || gdesc->rcd.udp) &&
 				     !(le32_to_cpu(gdesc->dword[0]) &
@@ -1465,6 +1466,7 @@ vmxnet3_rx_csum(struct vmxnet3_adapter *adapter,
 			if ((le32_to_cpu(gdesc->dword[0]) &
 				     (1UL << VMXNET3_RCD_HDR_INNER_SHIFT))) {
 				skb->csum_level = 1;
+				skb->encapsulation = 1;
IIRC ->encapsulation means that ->inner.. fields are valid, no?
And I don't see you setting any of these.

Paolo, please keep me honest, IIUC you have very recent and very
relevant experience with virtio.
Yes. Specifically the GSO code expect the inner headers to be set,
otherwise the segmentation will yield quite wrong results.

Note that reproducing the issue requires a quite specific setup, i.e.
bridging (or tc redirecting) the ingress traffic from an
UDP-tunnel-HW-GRO enabled device into an egress device not supporting
tx-udp_tnl-segmentation.

If otherwise the traffic goes into the UDP tunnel rx path, such
processing will set the needed field correctly and no issue could/should
be observed AFAICS.

@Ronak: I think the problem pre-exists this specific patch, but since
you are fixing the relevant offload, I think it should be better to
address the problem now.

Thanks,

Paolo



Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help