netdev - Re: [PATCH net-next 2/4] sfc: implement encap TSO on EF100

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 30 Oct 2020 16:55:54 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Willem de Bruijn <willemdebruijn.kernel@...il.com>,
        linux-net-drivers@...arflare.com, Jakub Kicinski <kuba@...nel.org>,
        David Miller <davem@...emloft.net>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 2/4] sfc: implement encap TSO on EF100

On Fri, Oct 30, 2020 at 2:14 PM Edward Cree <ecree@...arflare.com> wrote:
>
> On 30/10/2020 17:33, Willem de Bruijn wrote:
> > On Fri, Oct 30, 2020 at 12:43 PM Edward Cree <ecree@...arflare.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.

Perhaps the local TCP stack tries to avoid it. Off the top of my head
not sure if this is assured in all edge cases.

The forwarding path is another wildcard.

> > 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.

Oh right.

> 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