netdev - Re: [PATCH RFC net-next] net: dsa: Provide CPU port statistics to master netdev

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:	Tue, 26 Apr 2016 12:44:50 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Andrew Lunn <andrew@...n.ch>
Cc:	netdev@...r.kernel.org, davem@...emloft.net,
	vivien.didelot@...oirfairelinux.com
Subject: Re: [PATCH RFC net-next] net: dsa: Provide CPU port statistics to
 master netdev

On 25/04/16 14:43, Andrew Lunn wrote:
> On Wed, Apr 20, 2016 at 10:58:21AM -0700, Florian Fainelli wrote:
>> This patch overloads the DSA master netdev, aka CPU Ethernet MAC to also
>> include switch-side statistics, which is useful for debugging purposes,
>> when the switch is not properly connected to the Ethernet MAC (duplex
>> mismatch, (RG)MII electrical issues etc.).
>>
>> We accomplish this by retaining the original copy of the master netdev's
>> ethtool_ops, and just overload the 3 operations we care about:
>> get_sset_count, get_strings and get_ethtool_stats so as to intercept
>> these calls and call into the original master_netdev ethtool_ops, plus
>> our own.
> 
> Hi Florian
> 
> Interesting concept. My one concern is that by concatenating the two
> sets of statistics, we get a name clash. I'm not sure the Marvell
> switch statistics counters have different names to the Marvell
> Ethernet driver statistics counters. ethtool does not care, but maybe
> an SNMP agent using these statistics might not be too happy seeing the
> same name twice?

That's a very good point, would you agree if we were prefixing the DSA
CPU port statistics with some kind of name, e.g: cpu_port_<name> or
something more compact?
-- 
Florian