From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
pabeni@redhat.com, Vladimir Oltean <olteanv@gmail.com>,
andrew@lunn.ch, hkallweit1@gmail.com, linux@armlinux.org.uk,
woojung.huh@microchip.com, o.rempel@pengutronix.de
Subject: Re: [RFC net-next 1/2] net: ethtool: plumb PHY stats to PHY drivers
Date: Fri, 30 Aug 2024 10:16:30 +0200 [thread overview]
Message-ID: <20240830101630.52032f20@device-28.home> (raw)
In-Reply-To: <20240829174342.3255168-2-kuba@kernel.org>
Hello Jakub,
On Thu, 29 Aug 2024 10:43:41 -0700
Jakub Kicinski <kuba@kernel.org> wrote:
> Feed the existing IEEE PHY counter struct (which currently
> only has one entry) and link stats into the PHY driver.
> The MAC driver can override the value if it somehow has a better
> idea of PHY stats. Since the stats are "undefined" at input
> the drivers can't += the values, so we should be safe from
> double-counting.
>
> Vladimir, I don't understand MM but doesn't MM share the PHY?
> Ocelot seems to aggregate which I did not expect.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[...]
> +static void
> +ethtool_get_phydev_stats(struct net_device *dev,
> + struct linkstate_reply_data *data)
> +{
> + struct phy_device *phydev = dev->phydev;
This would be a very nice spot to use the new
ethnl_req_get_phydev(), if there are multiple PHYs on that device.
Being able to access the stats individually can help
troubleshoot HW issues.
[...]
> +static void
> +ethtool_get_phydev_stats(struct net_device *dev, struct stats_reply_data *data)
> +{
> + struct phy_device *phydev = dev->phydev;
Here as well, but that's trickier, as the MAC can override the PHY
stats, but it doesn't know which PHY were getting the stats from.
Maybe we could make so that when we pass a phy_index in the netlink
command, we don't allow the mac to override the phy stats ? Or better,
don't allow the mac to override these stats and report the MAC-reported
PHY stats alongside the PHY-reported stats ?
> +
> + if (!phydev || !phydev->drv || !phydev->drv->get_phy_stats)
> + return;
> +
> + mutex_lock(&phydev->lock);
> + phydev->drv->get_phy_stats(phydev, &data->phy_stats);
> + mutex_unlock(&phydev->lock);
> +}
> +
> static int stats_prepare_data(const struct ethnl_req_info *req_base,
> struct ethnl_reply_data *reply_base,
> const struct genl_info *info)
> @@ -145,6 +160,10 @@ static int stats_prepare_data(const struct ethnl_req_info *req_base,
> data->ctrl_stats.src = src;
> data->rmon_stats.src = src;
>
> + if (test_bit(ETHTOOL_STATS_ETH_PHY, req_info->stat_mask) &&
> + src == ETHTOOL_MAC_STATS_SRC_AGGREGATE)
> + ethtool_get_phydev_stats(dev, data);
I might be missing something, but I think
ETHTOOL_MAC_STATS_SRC_AGGREGATE is a MM-specific flag and I don't really
see how this applies to getting the PHY stats. I don't know much about
MM though so I could be missing the point.
I'm all in for getting the PHY stats from netlink though :)
Thanks,
Maxime
next prev parent reply other threads:[~2024-08-30 8:16 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 [this message]
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
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=20240830101630.52032f20@device-28.home \
--to=maxime.chevallier@bootlin.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=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=olteanv@gmail.com \
--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;
as well as URLs for NNTP newsgroup(s).