On 30/10/2020 17:33, Willem de Bruijn wrote: > On Fri, Oct 30, 2020 at 12:43 PM Edward Cree <ec...@solarflare.com> wrote: >> But possibly I don't need to have NETIF_F_GSO_UDP_TUNNEL[_CSUM] in >> net_dev->gso_partial_features? > If the device can handle fixing the odd last segment length, indeed. It can, but... I thought Linux didn't give drivers odd last segments any more. At least I'm fairly sure that in the (non-PARTIAL) non-encap TSO tests I've done, the GSO skbs we've been given have all been a whole number of mss long. Which means I haven't been able to test that the device gets it right.
> Until adding other tunnel types like NETIF_F_GSO_GRE_CSUM, for this > device gso_partial_features would then be 0 and thus > NETIF_F_GSO_PARTIAL is not needed at all? Unless the kernel supports GSO_PARTIAL of nested tunnels. The device will handle (say) VxLAN-in-VxLAN just fine, as long as you don't want it to update the middle IPID; and being able to cope with crazy things like that was (I thought) part of the point of GSO_PARTIAL. Indeed, given that GSO_PARTIAL is supposed to be a non-protocol- ossified design, it seems a bit silly to me that we have to specify a list of other NETIF_F_GSO_foo, rather than just being able to say "I can handle anything of the form ETH-IP-gubbins-IP-TCP" and let the kernel put whatever it likes — VxLAN, GRE, fou-over-geneve with cherry and sprinkles — in the 'gubbins'. Wasn't that what 'less is more' was supposed to be all about? -ed
