[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0824bc9f-ac6d-4fe9-9c1b-b0523959741e@redhat.com>
Date: Fri, 23 May 2025 08:44:26 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>, netdev@...r.kernel.org
Cc: Jason Wang <jasowang@...hat.com>, Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, "Michael S. Tsirkin" <mst@...hat.com>,
Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, Eugenio Pérez
<eperezma@...hat.com>
Subject: Re: [PATCH net-next 5/8] net: implement virtio helpers to handle UDP
GSO tunneling.
On 5/23/25 8:09 AM, Paolo Abeni wrote:
> On 5/23/25 12:29 AM, Willem de Bruijn wrote:
>> Paolo Abeni wrote:
>>> + /* No UDP fragments over UDP tunnel. */
>>
>> What are udp fragments and why is TCP with ECN not supported?
>
> "udp fragments" is the syncopated form of "UDP datagrams carryed by IP
> fragments". I'll use UFO to be clearer ;)
>
> The ECN part is cargo cult on my side from my original implementation
> which dates back to ... a lot of time ago. A quick recheck makes me
> think I could drop it. I'll have a better look and either document the
> choice or drop the check in the next revision.
Let me quote the relevant code:
>>> + gso_inner_type = hdr->gso_type & ~(VIRTIO_NET_HDR_GSO_ECN |
>>> + gso_tunnel_type);
>>> + if (!gso_inner_type || gso_inner_type == VIRTIO_NET_HDR_GSO_UDP)
>>> + return -EINVAL;
Actually GSO_ECN is allowed. What is _not_ allowed is the GSO_ECN
offload without a paired plain GSO. The intention here is to ensure that
the GSO over UDP tunnel packets actually includes/requires an inner GSO
offload. I'll update the comment accordingly.
Thanks,
Paolo
Powered by blists - more mailing lists