netdev - Re: [RFC net-next 1/2] net: ethtool: plumb PHY stats to PHY drivers

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: <20240902150845.jze45qvx4k3n7ijz@skbuf>
Date: Mon, 2 Sep 2024 18:08:45 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
	pabeni@...hat.com, andrew@...n.ch, hkallweit1@...il.com,
	linux@...linux.org.uk, woojung.huh@...rochip.com,
	o.rempel@...gutronix.de, maxime.chevallier@...tlin.com
Subject: Re: [RFC net-next 1/2] net: ethtool: plumb PHY stats to PHY drivers

On Thu, Aug 29, 2024 at 10:43:41AM -0700, Jakub Kicinski wrote:
> Vladimir, I don't understand MM

MAC Merge / Frame Preemption in a nutshell:

- Frame is express if, after the preamble, it has a "normal" SFD of 0xD5

- Frame is preemptible if, after the preamble, it has an SFD of 0x07,
  0x19, 0xE6, 0x4C, 0x7F, 0xB3, 0x61, 0x52, 0x9E or 0x2A

express MAC handles express frames
preemptible MAC handles preemptible frames

ETHTOOL_MAC_STATS_SRC_EMAC counts express frames
ETHTOOL_MAC_STATS_SRC_PMAC counts preemptible frames
ETHTOOL_MAC_STATS_SRC_AGGREGATE counts both - also works when you don't know

Now you know as much as I do.

> but doesn't MM share the PHY?

It does, yes. There is a single set of MII lines, and distinction
between the express and preemptible MAC is done as described above.

I wouldn't expect the PHY to be aware of MAC Merge / Frame Preemption,
and thus, this component would normally not pay attention to the SFD of
the frames it's counting. The entire feature actually depends on the PHY
being unaware of the SFD, because they don't make PHYs "for" frame preemption.

Although, imaginably, just like we have PHYs which emit PAUSE frames,
and that technically means they have a MAC embedded inside, it would not
be impossible to twist standards such that the PHY handles FPE/MM.
This is only in the realm of theory, AFAIU, and I'm not suggesting we
should model the UAPI based on pure theory.

> Ocelot seems to aggregate which I did not expect.

Ocelot aggregates stats when the request is to aggregate them
(explicit ETHTOOL_MAC_STATS_SRC_AGGREGATE, and also default, for
comparability/ compatibility with unaware drivers). Otherwise it
reports them individually.

Also, the stats it reports into phy_stats->SymbolErrorDuringCarrier are
MAC stats. They count the number of frames received by the MAC with
RX_ER being asserted on the MII interface. So these could be counted by
either the MAC, or the PHY. The MAC is MM-aware, the PHY is probably not.

Though if I follow the thread, I'm not sure if this is exactly useful to
Oleksij, who would like to report an entirely different set of counters.

I never got the impression that the ETHTOOL_STATS_ETH_PHY structured
netlink counters were for NICs with embedded non-phylib PHYs. If they
are - sorry. I thought it was about those MAC counters which are
collected at the interface with the PHY.