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  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:	Thu, 12 May 2016 15:23:13 -0700
From:	Florian Fainelli <>
To:	Roopa Prabhu <>
Cc:	Jiri Pirko <>, netdev <>,
	David Miller <>,,
	Ido Schimmel <>,
	Elad Raz <>,
	Yotam Gigi <>,
	ogerlitz <>,
	Nikolay Aleksandrov <>,
	John Linville <>, tgraf <>,
	Andy Gospodarek <>,
	Scott Feldman <>,
	Sabrina Dubroca <>,
	Eran Ben Elisha <>,
	Alexei Starovoitov <>,
	Eric Dumazet <>,
	Hannes Frederic Sowa <>
Subject: Re: [patch net-next 1/4] netdevice: add SW statistics ndo

2016-05-12 14:10 GMT-07:00 Roopa Prabhu <>:
> On 5/12/16, 4:48 AM, Jiri Pirko wrote:
>> From: Nogah Frankel <>
>> Till now we had a ndo statistics function that returned SW statistics.
>> We want to change the "basic" statistics to return HW statistics if
>> available.
>> In this case we need to expose a new ndo to return the SW statistics.
>> Add a new ndo declaration to get SW statistics
>> Add a function that gets SW statistics if a competible ndo exist
>> Signed-off-by: Nogah Frankel <>
>> Reviewed-by: Ido Schimmel <>
>> Signed-off-by: Jiri Pirko <>
>> ---
> To me netdev stats is  combined 'SW + HW' stats for that netdev.
> ndo_get_stats64 callback into the drivers does the magic of adding HW stats
> to SW (netdev) stats and returning (see enic_get_stats). HW stats is available for netdevs
> that are offloaded or are backed by hardware. SW stats is the stats that the driver maintains
> (logical or physical). HW stats is queried and added to the SW stats.
> In fact, we represent all our offloaded netdev stats following this model.
> This fits well for logical devices like vlan/bond/vxlan which are hardware offloaded too.

Agreed, if you take a look at what the DSA slave network devices do in
net/dsa/slave.c they basically overload the switch-mainainted
statistics with some per-port net_device software stats. We would
probably want to do the same thing

> There is HW extended stats which today are represented by ethtool
> and I had an example of a new nested attribute like IFLA_STATS_LINK_HW_EXTENDED
> to provide ethtool like extensible stats. If people want pure hardware stats, they
> get it via this. In which case I am not seeing the point in adding a new ndo and a new
> stats attribute just for this. If you are looking for pure hardware stats, any reason we cant
> just use the IFLA_STATS_LINK_HW_EXTENDED and add ethtool like hw stats ?.
> This will be one place to look for all hardware stats and will be extensible too.

Agreed, worste case, you format your statistics such that they reflect
they come from the HW (e.g: hw_TxOctets...)

Powered by blists - more mailing lists