Messages in this thread | | | From | Willem de Bruijn <> | Date | Mon, 2 Nov 2020 10:14:02 -0500 | Subject | Re: [PATCH net-next] net: avoid unneeded UDP L4 and fraglist GSO resegmentation |
| |
On Sat, Oct 31, 2020 at 11:56 AM Alexander Lobakin <alobakin@pm.me> wrote: > > From: Willem de Bruijn <willemdebruijn.kernel@gmail.com> > Date: Sat, 31 Oct 2020 11:26:24 -0400 > > >>>> I think it is fine to reenable this again, now that UDP sockets will > >>>> segment unexpected UDP GSO packets that may have looped. We previously > >>>> added general software support in commit 83aa025f535f ("udp: add gso > >>>> support to virtual devices"). Then reduced its scope to egress only in > >>>> 8eea1ca82be9 ("gso: limit udp gso to egress-only virtual devices") to > >>>> handle that edge case. > >> > >> Regarding bonding and teaming: I think they should also use > >> NETIF_F_GSO_SOFTWARE mask, not NETIF_F_ALL_TSO, as SCTP also has > >> a software fallback. This way we could also remove a separate > >> advertising of NETIF_F_GSO_UDP_L4, as it will be included in the first. > >> > >> So, if this one: > >> 1. Add NETIF_F_GSO_UDP_L4 and NETIF_F_GSO_FRAGLIST to > >> NETIF_F_GSO_SOFTWARE; > >> 2. Change bonding and teaming features mask from NETIF_F_ALL_TSO | > >> NETIF_F_GSO_UDP_L4 to NETIF_F_GSO_SOFTWARE; > >> 3. Check that every virtual netdev has NETIF_F_GSO_SOFTWARE _or_ > >> NETIF_F_GSO_MASK in its advertising. > >> > >> is fine for everyone, I'll publish more appropriate and polished v2 soon. > > > > I think we can revert 8eea1ca82be9. Except for the part where it > > defines the feature in NETIF_F_GSO_ENCAP_ALL instead of > > NETIF_F_GSO_SOFTWARE. That appears to have been a peculiar choice. I > > can't recall exactly why I chose that. Most likely because that was > > (at the time) the only macro that covered all the devices I wanted to > > capture. > > > > As for SCTP: that has the same concern that prompted that commit for > > UDP: is it safe to forward those packets to the ingress path today? > > Oh well. I just looked up into net/sctp/offload.c and see no GRO > receiving callbacks, only GSO ones. On the other hand, > NETIF_F_GSO_SOFTWARE includes GSO_SCTP and is used in almost every > virtual netdev driver, including macvlan and veth mentioned earlier, > so that seems to be fine.
To follow up: SCTP sockets can handle such packets. So both local reception and forwarding are fine. This was expressly added to the second revision of the SCTP GSO commit.
| |