Re: [net-next PATCH v2 0/8] UDP GSO Segmentation clean-ups

From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: Network Development <netdev@vger.kernel.org>,
	Willem de Bruijn <willemb@google.com>,
	David Miller <davem@davemloft.net>
Subject: Re: [net-next PATCH v2 0/8] UDP GSO Segmentation clean-ups
Date: Wed, 9 May 2018 11:39:37 -0400	[thread overview]
Message-ID: <CAF=yD-+=9EUjiT=ZG+G=phQcHmD8s3e6mydhBehddVCqL0pEGg@mail.gmail.com> (raw)
In-Reply-To: <CAKgT0UeKY_O16yPtArJeRa6-+zT4BDoYP-iFVK8YyccL0ZcQow@mail.gmail.com>

On Mon, May 7, 2018 at 2:02 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Sat, May 5, 2018 at 3:06 AM, Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
>> On Fri, May 4, 2018 at 8:28 PM, Alexander Duyck
>> <alexander.duyck@gmail.com> wrote:
>>> This patch set addresses a number of issues I found while sorting out
>>> enabling UDP GSO Segmentation support for ixgbe/ixgbevf. Specifically there
>>> were a number of issues related to the checksum and such that seemed to
>>> cause either minor irregularities or kernel panics in the case of the
>>> offload request being allowed to traverse between name spaces.
>>
>> Were you able to traverse GSO packets between network namespace before
>> adding to NETIF_F_GSO_SOFTWARE? It does appear that veth includes
>> NETIF_F_GSO_ENCAP_ALL, which also allows GSO.
>
> Without that change the tunnel wouldn't pass the requests between
> namespaces. However with it I was able to easily test the software
> checksum code as otherwise the socket was returning EIO when the
> hardware checksum was disabled.
>
>> In either case, it should not be possible for GSO packets to arrive on a veth
>> device, as that can result in queuing the GSO packet to a recipient socket.
>> In this regard veth is like loopback and must exclude GSO support.
>>
>> I'll take a look.
>
> I suspect it was probably sending veth UDP segmentation offload
> requests. For now I can probably drop he patch that was adding it and
> it can be added later to individual drivers if needed.

I just tested udpgso_bench_tx over veth (on a commit without your
patchset).

Having NETIF_F_GSO_UDP_L4 in NETIF_F_GSO_ENCAP_ALL
and NETIF_F_GSO_ENCAP_ALL in VETH_FEATURES is
sufficient to receive large packets on the veth peer.

This is clearly a bug, as is for any device that may loop packets
onto a local socket. Such as macvlan in bridge mode.

I will have to revise commit 83aa025f535f ("udp: add gso support
to virtual devices")

It remains useful to have this capability on the bonding device. I
might remove the flag from NETIF_F_GSO_ENCAP_ALL and add
it specifically to that device.

This is also all relevant to future work of NETIF_F_GSO_SOFTWARE.