Netdev List
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
	pabeni@redhat.com, andrew@lunn.ch, hkallweit1@gmail.com,
	linux@armlinux.org.uk, woojung.huh@microchip.com,
	o.rempel@pengutronix.de, maxime.chevallier@bootlin.com
Subject: Re: [RFC net-next 1/2] net: ethtool: plumb PHY stats to PHY drivers
Date: Mon, 2 Sep 2024 18:08:45 +0300	[thread overview]
Message-ID: <20240902150845.jze45qvx4k3n7ijz@skbuf> (raw)
In-Reply-To: <20240829174342.3255168-2-kuba@kernel.org>

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.

  parent reply	other threads:[~2024-09-02 15:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-29 17:43 [RFC net-next 0/2] net: ethtool: add phy(dev) specific stats over netlink Jakub Kicinski
2024-08-29 17:43 ` [RFC net-next 1/2] net: ethtool: plumb PHY stats to PHY drivers Jakub Kicinski
2024-08-29 18:10   ` Oleksij Rempel
2024-08-29 19:13     ` Jakub Kicinski
2024-08-30  8:16   ` Maxime Chevallier
2024-08-30 18:30     ` Jakub Kicinski
2024-09-04  7:20       ` Maxime Chevallier
2024-09-04  8:05         ` Oleksij Rempel
2024-09-04  8:09           ` Maxime Chevallier
2024-09-02 15:08   ` Vladimir Oltean [this message]
2024-08-29 17:43 ` [RFC net-next 2/2] net: ethtool: add phy(dev) specific stats over netlink Jakub Kicinski
2024-08-29 18:47   ` Andrew Lunn
2024-08-29 19:23     ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240902150845.jze45qvx4k3n7ijz@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=pabeni@redhat.com \
    --cc=woojung.huh@microchip.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox