netdev - Re: [PATCH net-next 06/14] net: dev: Add hardware stats support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20220224222244.0dfadb8b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Thu, 24 Feb 2022 22:22:44 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Ido Schimmel <idosch@...dia.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, petrm@...dia.com,
        jiri@...dia.com, razor@...ckwall.org, roopa@...dia.com,
        dsahern@...il.com, andrew@...n.ch, mlxsw@...dia.com
Subject: Re: [PATCH net-next 06/14] net: dev: Add hardware stats support

On Thu, 24 Feb 2022 15:33:27 +0200 Ido Schimmel wrote:
> From: Petr Machata <petrm@...dia.com>
> 
> Offloading switch device drivers may be able to collect statistics of the
> traffic taking place in the HW datapath that pertains to a certain soft
> netdevice, such as VLAN. Add the necessary infrastructure to allow exposing
> these statistics to the offloaded netdevice in question. The API was shaped
> by the following considerations:
> 
> - Collection of HW statistics is not free: there may be a finite number of
>   counters, and the act of counting may have a performance impact. It is
>   therefore necessary to allow toggling whether HW counting should be done
>   for any particular SW netdevice.
> 
> - As the drivers are loaded and removed, a particular device may get
>   offloaded and unoffloaded again. At the same time, the statistics values
>   need to stay monotonous (modulo the eventual 64-bit wraparound),

monotonic

>   increasing only to reflect traffic measured in the device.

> +	struct rtnl_link_stats64 *offload_xstats_l3;

Does it make sense to stick to rtnl_link_stats64 for this?
There's a lot of.. historical baggage in that struct.