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

[Jakub Kicinski <kuba@kernel.org>]

On Mon, 15 Jul 2024 18:05:43 +0300 Vladimir Oltean wrote:
> 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?

The information about rings can be computed based on channels as
currently used by drivers.

> 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

They can provide a different number? Which number is the user
supposed to trust? Out of the 4 APIs we have? Or the NIC has
a different ring count depending on the API?

> 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

Why not also look up "for lack of a better word" :|

> > 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?

IDK what you mean, given the slice of my message you're responding to.

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

You are missing the fact that other parts of the stack use different
APIs. Why does RXFH need its own way of reading queue count if we have
channels and rx queue count in rtnl?

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

Plainly :|