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

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

On Mon, Jul 15, 2024 at 08:26:00AM -0700, Jakub Kicinski wrote:
> The information about rings can be computed based on channels as
> currently used by drivers.
(...)
> 
> 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?

To stay on point on GRXRINGS vs GCHANNELS, "man ethtool" does say
"A channel is an IRQ and the set of queues that can trigger that IRQ."
Doesn't sound either (a) identical or (b) that you can recover the # of
rings from the # of channels, unless you make an assumption about how
they are distributed to IRQs...

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

Not connected to that particular sentence, it's just a comment about the
lack of consistency implied by your proposal, placed at the end of your
quoted email.

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

Maybe if introduced today, it wouldn't have to, but the more relevant
question for my situation here is "why change it?"

I only expressed my dislike of a netlink/no netlink inconsistency
because your question was seemingly addressed to me. Luckily I am not
the one who needs to make that decision and I will gladly test out any
patch that fixes the regression.