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]

Date:   Mon, 14 Sep 2020 09:15:18 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, mkubecek@...e.cz,
        michael.chan@...adcom.com, tariqt@...dia.com, saeedm@...dia.com,
        alexander.duyck@...il.com, andrew@...n.ch
Subject: Re: [PATCH net-next v2 0/8] ethtool: add pause frame stats

On Sat, 12 Sep 2020 10:16:12 +0300 Vladimir Oltean wrote:
> > You can still append your custom CPU port stats to ethtool -S or
> > debugfs or whatnot,  
> 
> I don't understand, so you're saying that DSA can keep pause stats
> reporting in "ethtool -S", but the rest of devices should move to
> "ethtool -a"?

I'm saying report pause stats via the new interface on normal ports
which have a netdev (external switch ports, CPU MAC).

Deal with the weird CPU port in other, correspondingly weird, ways, 
like ethtool -S :)

> You know that a typical switching chip will report the
> same statistics counters on all ports, including the ones that do have a
> net_device, right?  

I never used a DSA device. But I was under the impression they were
supposed to be modeled like separate NICs..

> So DSA gets a waiver from implementing .get_pause_stats()?
> 
> > but those are only useful for validating that the configuration of the
> > CPU port is not completely broken. Otherwise the counters are
> > symmetrical. A day-to-day user of the device doesn't need to see both
> > of them.  
> 
> A day-to-day user shouldn't need to look at ethtool -S or any other
> statistics for that matter, either. If they need to look at flow control
> on the CPU port they'd better get the full story rather than half of it.

Flow control stats are a really important piece of data on how 
the network operates. And they are part of normal operation of 
the network.

Stats on the "CPU port" should be symmetrical with the CPU MAC.

> Sorry for the non-constructive answer. Like Florian said, it would be
> nice to have some built-in mechanism for this new ndo that DSA could use
> to keep annotating its own stats.

I do sympathize with the challenges of DSA. I never had any good ideas
on how to help with it, TBH. I feel like this is a larger challenge,
adding stats to the already existing (and problematic from DSA
perspective) interface to configure pause frames is not changing the
situation all that much.