On Wed, May 9, 2018 at 8:39 AM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > On Mon, May 7, 2018 at 2:02 PM, Alexander Duyck > <alexander.du...@gmail.com> wrote: >> On Sat, May 5, 2018 at 3:06 AM, Willem de Bruijn >> <willemdebruijn.ker...@gmail.com> wrote: >>> On Fri, May 4, 2018 at 8:28 PM, Alexander Duyck >>> <alexander.du...@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.
Sounds like a plan. In the meantime I am going to see about getting some internal paperwork taken care of to get UDP GSO added to ixgbe/ixgbevf as an official feature. I need to finish up some work I am doing on macvlan over the next couple of weeks so I won't be focusing on this code for the next month or so. Thanks. - Alex