Re: [PATCH net-next v4 0/5] ionic: Expose more port stats to ethtool

[Eric Joyner <eric.joyner@amd.com>]

On 6/13/2026 4:53 PM, Jakub Kicinski wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
> 
> 
> On Tue, 9 Jun 2026 23:18:25 -0700 Eric Joyner wrote:
>> - The link_down_count from firmware mentioned in v2 was moved back to an
>>   entry in the general ethtool statistics; the existing driver-calculated
>>   value for the ethtool ext link is more appropriate due to the firmware
>>   value being a small size and not resetting between driver loads.
> 
> There's a uAPI stat defined for something but you don't use it because
> you can't be bothered to handle overflow and reset? What am I missing :/

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.

- Eric