netdev - Re: Why not replace NETIF_F_UDP_GRO_FWD and NETIF_F_GRO_FRAGLIST with the same trick used by NETIF_F_UDP_GRO_FWD and rename it NETIF_F_UDP

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>] [day] [month] [year] [list]

Message-ID: <CA+FuTScLNosPjZvo4vPaq1A7ZJGdA1svc+hhxz25g=uwQxWgGg@mail.gmail.com>
Date: Tue, 30 Apr 2024 14:58:04 -0400
From: Willem de Bruijn <willemb@...gle.com>
To: Shi Xudong <shixudong@....com>
Cc: "alobakin@...me" <alobakin@...me>, "kuba@...nel.org" <kuba@...nel.org>, netdev <netdev@...r.kernel.org>, 
	Paolo Abeni <pabeni@...hat.com>, Steffen Klassert <steffen.klassert@...unet.com>, 
	Willem de Bruijn <willemdebruijn.kernel@...il.com>
Subject: Re: Why not replace NETIF_F_UDP_GRO_FWD and NETIF_F_GRO_FRAGLIST with
 the same trick used by NETIF_F_UDP_GRO_FWD and rename it NETIF_F_UDP_GRO?

On Tue, Apr 30, 2024 at 10:24 AM Shi Xudong <shixudong@....com> wrote:
>
> i understand:
> - both NETIF_F_UDP_GRO_FWD and NETIF_F_GRO_FRAGLIST is off - no UDP GRO;
>  - NETIF_F_UDP_GRO_FWD is on, NETIF_F_GRO_FRAGLIST is off - classic GRO;
>  - both NETIF_F_UDP_GRO_FWD and NETIF_F_GRO_FRAGLIST is on - fraglisted UDP GRO.
> and
> Plain UDP GRO forwarding even shows better performance than fraglisted UDP GRO in some cases due to not wasting one skbuff_head per every segment.
> but i have a question?
> Why not replace NETIF_F_UDP_GRO_FWD and NETIF_F_GRO_FRAGLIST with the same trick used by NETIF_F_UDP_GRO_FWD and rename it NETIF_F_UDP_GRO,

What trick are you referring to?

> implement local input and forward using plain UDP GRO packets, because "Classic" UDP GRO shows better performance when forwarding to a NIC
> that supports GSO UDP L4.

There are three targets for UDP GRO
1. local sockets
2. forwarding without hardware offload
3. forwarding with hardware offload

Non-fraglist is preferable for 1 and 3. But at GRO time it is not
possible to distinguish between 2 and 3.

This discussion is largely independent from the below bug report.
Those need a narrow fix, not a feature change.

>
> ________________________________
> shixudong@....com
>
>
> From: Willem de Bruijn
> Date: 2024-04-07 06:35
> To: Shi Xudong
> CC: alobakin@...me; kuba@...nel.org
> Subject: Re: fix bridge,bonding,team: advertise NETIF_F_GSO_SOFTWARE and extend NETIF_F_GSO_SOFTWARE include NETIF_F_SG,NETIF_F_FRAGLIST
> On Wed, Apr 3, 2024 at 11:11 AM Shi Xudong <shixudong@....com> wrote:
> >
> >
> > According to https://github.com/torvalds/linux/commit/2e4ef10f58502323ea470bc30ba84d5ddd4e77f0
> >
> > bridge,bonding,team  seem to  use netdev_increment_features to fix logical netdevs'feature,cause them to lose the NETIF_F_GSO_SOFTWARE feature (unless the real netdevs have the NETIF_F_GSO_SOFTWARE feature).In addition, plain UDP GSO/GRO, like TSO,  also relies on NETIF_F_SG.
> > UDP fraglist GRO/GSO also depends on NETIF_F_FRAGLIST.
> > Therefore, the following two modifications are recommended for bridge,bonding, and team:
> > 1.netdev_features.h
> > #define NETIF_F_GSO_SOFTWARE (NETIF_F_ALL_TSO | NETIF_F_GSO_SCTP |      \
> > +                                 NETIF_F_SG | NETIF_F_FRAGLIST | \
> > NETIF_F_GSO_UDP_L4 | NETIF_F_GSO_FRAGLIST)
> >
> > 2.netdevice.h
> > -/* Allow TSO being used on stacked device :
> > +/* Allow TSO/USO being used on stacked device :
> >  * Performing the GSO segmentation before last device
> >  * is a performance improvement.
> >  */
> > static inline netdev_features_t netdev_add_tso_features(netdev_features_t features,
> >                                                         netdev_features_t mask)
> > {
> > - return netdev_increment_features(features, NETIF_F_ALL_TSO, mask);
> > +      return netdev_increment_features(features, NETIF_F_ALL_TSO|NETIF_F_GSO_SOFTWARE, mask);
> > }
>
> Thanks for the report.
>
> Happy to respond, if you don't mind me cc:ing the public
> netdev@...r.kernel.org list.
>
> The list has more experts on this code, and such discussions are
> better public and archived for later understanding.