Re: Netlink handler for ethtool --show-rxfh breaks driver compatibility

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Mon, Jul 15, 2024 at 06:39:31AM -0700, Jakub Kicinski wrote:
> The definition I have in mind is that the design can't be well
> understood without taking into account the history, i.e. the order
> in which things were developed and the information we were working
> with at the time.
> 
> In this case, simply put, GRXRINGS was added well before GCHANNELS
> and to assign any semantic distinction between GRXRINGS and GCHANNELS 
> is revisionist, for lack of a better word.

Are you saying a channel is a ring?

Semantical differences / lack thereof aside - it is factually not the
same thing to report a number retrieved through a different UAPI
interface in the netlink handler variant for the same command.
You have the chance of either reporting a different number on the same
NIC, or GCHANNELS not being implemented by its driver.

revisionist
noun
someone who examines and tries to change existing beliefs about how
events happened or what their importance or meaning is

> I could be wrong, but that's what I meant by "historic coincidence".

And the fact that ethtool --show-rxfh uses GCHANNELS when the kernel is
compiled with CONFIG_ETHTOOL_NETLINK support, but GRXRINGS when it isn't,
helps de-blur the lines how?

I can't avoid the feeling that introducing GCHANNELS into the mix is
what is revisionist :( I hope I'm not missing something.

I'm just a simple user, I came here because the command stopped working,
not because I want to split hairs.