On Fri, Oct 30, 2020 at 12:43 PM Edward Cree <ec...@solarflare.com> wrote:
>
> On 30/10/2020 16:26, Willem de Bruijn wrote:
> > Then you could (as follow-up) advertise without GSO_PARTIAL and avoid
> > the whole transition through the gso layer?
>
> The thing is, non-PARTIAL offload only supports tunnels that the NIC
> understands (single-layer UDP tunnels), but AIUI GSO_PARTIAL can
> support all sorts of other things, such as gretaps (though we'd need
> some more advertised features, I haven't figured out quite which
> ones yet but when I do and can test it I'll send a follow-up) and
> nested tunnels (as long as we don't need to edit the 'middle' IP ID,
> e.g. if it's DF or IPv6). So we definitely want to advertise
> GSO_PARTIAL support.
> 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.
If you remove them from gso_partial_flags, then gso_features_check
won't mask them out
/* Support for GSO partial features requires software
* intervention before we can actually process the packets
* so we need to strip support for any partial features now
* and we can pull them back in after we have partially
* segmented the frame.
*/
if (!(skb_shinfo(skb)->gso_type & SKB_GSO_PARTIAL))
features &= ~dev->gso_partial_features;
as called in validate_xmit_skb prior to testing whether the packet can
be passed to the nic as is in netif_needs_gso.
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?
