netdev - Re: [PATCH net-next v2 0/8] ethtool: add pause frame stats

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]

Message-ID: <20200914122016.759eb786@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 14 Sep 2020 12:20:16 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>, davem@...emloft.net,
        netdev@...r.kernel.org, mkubecek@...e.cz,
        michael.chan@...adcom.com, tariqt@...dia.com, saeedm@...dia.com,
        alexander.duyck@...il.com
Subject: Re: [PATCH net-next v2 0/8] ethtool: add pause frame stats

On Mon, 14 Sep 2020 19:36:50 +0200 Andrew Lunn wrote:
> > > Can we consider using get_ethtool_stats and ETH_SS_PAUSE_STATS as a 
> > > stringset identifier? That way there is a single point within driver to 
> > > fetch stats.  
> > 
> > Can you say more? There are no strings reported in this patch set.  
> 
> Let me ask another question. Is pause stats the end of the story? Or
> do you plan to add more use case specific statistics?
> 
> ethtool -T|--show-time-stamping could show statistics for PTP frames
> sent/received?
> 
> ethtool --show-eee could show statistics for sleep/wake cycles?
> 
> ethtool --show-rxfh-indir could show RSS statistics?

I don't have a need for any of these. But they may make sense.

I'll add FEC stats next:

  30.5.1.1.17 aFECCorrectedBlocks
  30.5.1.1.18 aFECUncorrectableBlocks

I was tempted to add RMON stats, cause a lot of MACs expose those,
but I don't actually have a use for them personally, so it's lower 
prio.

> Would you add a new ethtool op for each of these? Or maybe we should
> duplex them all through get_ethtool_stats()?

I don't see a problem with an op for each of those. It makes for 
natural querying granularity. Works quite well for drivers converted
here, IMHO.