On 30/10/2020 17:33, Willem de Bruijn wrote:

On Fri, Oct 30, 2020 at 12:43 PM Edward Cree [off-list ref] wrote:

quoted

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