netdev - Re: [PATCHv3 net-next 09/10] net: add gso_ipv4_max_size and gro_ipv4_max

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, 27 Jan 2023 18:48:40 +0100
From:   Eric Dumazet <edumazet@...gle.com>
To:     Xin Long <lucien.xin@...il.com>
Cc:     network dev <netdev@...r.kernel.org>, davem@...emloft.net,
        kuba@...nel.org, Paolo Abeni <pabeni@...hat.com>,
        David Ahern <dsahern@...il.com>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Pravin B Shelar <pshelar@....org>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Florian Westphal <fw@...len.de>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Ilya Maximets <i.maximets@....org>,
        Aaron Conole <aconole@...hat.com>,
        Roopa Prabhu <roopa@...dia.com>,
        Nikolay Aleksandrov <razor@...ckwall.org>,
        Mahesh Bandewar <maheshb@...gle.com>,
        Paul Moore <paul@...l-moore.com>,
        Guillaume Nault <gnault@...hat.com>
Subject: Re: [PATCHv3 net-next 09/10] net: add gso_ipv4_max_size and
 gro_ipv4_max_size per device

On Fri, Jan 27, 2023 at 5:00 PM Xin Long <lucien.xin@...il.com> wrote:
>
> This patch introduces gso_ipv4_max_size and gro_ipv4_max_size
> per device and adds netlink attributes for them, so that IPV4
> BIG TCP can be guarded by a separate tunable in the next patch.
>
> To not break the old application using "gso/gro_max_size" for
> IPv4 GSO packets, this patch updates "gso/gro_ipv4_max_size"
> in netif_set_gso/gro_max_size() if the new size isn't greater
> than GSO_LEGACY_MAX_SIZE, so that nothing will change even if
> userspace doesn't realize the new netlink attributes.
>
> Signed-off-by: Xin Long <lucien.xin@...il.com>
> ---
>  include/linux/netdevice.h    |  6 ++++++
>  include/uapi/linux/if_link.h |  3 +++
>  net/core/dev.c               |  4 ++++
>  net/core/dev.h               | 18 ++++++++++++++++++
>  net/core/rtnetlink.c         | 33 +++++++++++++++++++++++++++++++++
>  5 files changed, 64 insertions(+)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 63b77cbc947e..ce075241ec47 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -2010,6 +2010,9 @@ enum netdev_ml_priv_type {
>   *                     SET_NETDEV_DEVLINK_PORT macro. This pointer is static
>   *                     during the time netdevice is registered.
>   *
> + *     @gso_ipv4_max_size:     Maximum size of IPv4 GSO packets.
> + *     @gro_ipv4_max_size:     Maximum size of IPv4 GRO packets.
> + *
>   *     FIXME: cleanup struct net_device such that network protocol info
>   *     moves out.
>   */
> @@ -2362,6 +2365,9 @@ struct net_device {
>         struct rtnl_hw_stats64  *offload_xstats_l3;
>
>         struct devlink_port     *devlink_port;
> +
> +       unsigned int            gso_ipv4_max_size;
> +       unsigned int            gro_ipv4_max_size;

This seems a pretty bad choice in terms of data locality.

Field order in "struct net_device" is very important for performance.

Please put gro_ipv4_max_size close to other related fields, so that we
do not need an extra cache line miss.

Same for gso_ipv4_max_size.

Use "pahole --hex" to study how "struct net_device" is currently partitioned.
It seems we have a hole after tso_max_segs, so this would be for
gso_ipv4_max_size


>  };
>  #define to_net_dev(d) container_of(d, struct net_device, dev)
>
>