From: Jakub Kicinski <kuba@kernel.org>
To: Eric Joyner <eric.joyner@amd.com>
Cc: netdev@vger.kernel.org, Brett Creeley <brett.creeley@amd.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Jacob Keller <jacob.e.keller@intel.com>
Subject: Re: [PATCH net-next v4 0/5] ionic: Expose more port stats to ethtool
Date: Mon, 15 Jun 2026 10:03:14 -0700 [thread overview]
Message-ID: <20260615100314.1c0caac4@kernel.org> (raw)
In-Reply-To: <4f6de4ed-c687-4d1b-86fd-1c8e63e08fb3@amd.com>
On Sat, 13 Jun 2026 18:34:23 -0700 Eric Joyner wrote:
> I could add the overflow and reset handling (I was working on it for a v5), but
> to me, it didn't seem like it was worth the effort to modify the stat from
> firmware instead of continuing to use the existing driver-calculated stat. It
> wasn't really a "can I do this" question but more "is it worth doing this?"
>
> To start, it didn't seem like there was a specific standard that the API
> expected; it looked like "copy straight from the adapter if you can, or just
> calculate something if you can't". It's hard to tell what the actual
> expectations for the interface outside of the struct comment since there aren't
> many drivers using it. The Mellanox and Broadcom driver stat handlers just read
> the link down count straight from hardware (though I don't know if those stats
> get reset on driver load or reboot and we're the outlier in the way our firmware
> behaves). The Intel drivers are similar to what we do now in the ionic driver,
> and they just count the link down events that the driver detects, but I know
> that they don't expose a link down count from the hardware. What we do now
> seems good enough for that purpose? It's bigger than 16 bits and gets reset on
> driver load, so why add more code to handle something that this seems to do well
> enough?
>
> But, I also still want the raw firmware stat because the firmware has a
> different lifetime than the driver, and so it will count link down events while
> the driver isn't loaded or in a state to receive link events. But since maybe
> that's only useful for debugging, it belongs in debugfs instead? I just thought
> drivers could more or less put what they want in `ethtool -S` output, so that
> seemed like an okay place to put it.
I sent a patch to delete this incorrect stat ASAP. Feel free to add it
to ethtool -S under a name that clearly indicates that it's _not_ the
phy down count in the next cycle.
prev parent reply other threads:[~2026-06-15 17:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-10 6:18 [PATCH net-next v4 0/5] ionic: Expose more port stats to ethtool Eric Joyner
2026-06-10 6:18 ` [PATCH net-next v4 1/5] ionic: Fix check in ionic_get_link_ext_stats Eric Joyner
2026-06-10 6:18 ` [PATCH net-next v4 2/5] ionic: Update ionic_if.h with new extra port stats Eric Joyner
2026-06-10 6:18 ` [PATCH net-next v4 3/5] ionic: Report "rx_bits_phy" stat to ethtool Eric Joyner
2026-06-10 6:18 ` [PATCH net-next v4 4/5] ionic: Report "link_down_events_phy" in ethtool statistics Eric Joyner
2026-06-10 6:18 ` [PATCH net-next v4 5/5] ionic: Add .get_fec_stats ethtool handler Eric Joyner
2026-06-12 9:18 ` [PATCH net-next v4 0/5] ionic: Expose more port stats to ethtool Simon Horman
2026-06-14 20:54 ` Eric Joyner
2026-06-13 23:53 ` Jakub Kicinski
2026-06-14 1:34 ` Eric Joyner
2026-06-15 17:03 ` Jakub Kicinski [this message]
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=20260615100314.1c0caac4@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=brett.creeley@amd.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.joyner@amd.com \
--cc=jacob.e.keller@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.