Re: [Intel-wired-lan] [PATCH net-next] e1000e: ethtool: add get_channels support

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 5 May 2026 01:12:29 +0000 Jon Kohler wrote:
> > On May 4, 2026, at 9:06 PM, Jakub Kicinski <kuba@kernel.org> wrote:
> > 
> > On Tue, 5 May 2026 00:59:40 +0000 Jon Kohler wrote:  
>  [...]  
>  [...]  
>  [...]  
> >> 
> >> Perhaps, but I’m not sure that is a guarantee. A good relevant example
> >> is when I added get_channels support to enic, which supports all sorts
> >> of channels, so I don’t think EOPNOTSUP can be 100% consider reliable
> >> in that case. Meaning, if it just so happens that the original author(s)
> >> didn't put in get_channels, that doesn’t necessarily mean there is only
> >> one queue.
> >> 
> >> And in this case, there is an "other" queue as as well too, as far as
> >> I can tell, so the output is at least semi-interesting.  
> > 
> > Sorry I wasn't clear enough - if you have an actual, real life use case
> > why you need queue count of 1 to be explicitly reported - please explain
> > it and put it in the commit message.
> > 
> > If you don't - please don't send patches for the sake of it.  
> 
> Ah, ok, sorry I misread your message, this isn’t a patch for the sake of
> a patch. Long story short, we’ve got a user space part of our control plane
> that reads in the output of ethtool -l as part of some broader queue
> management code. On systems with an e1000e device present, this specific
> component goes into a crash loop as it expects all NIC(s) to at least
> give it some sort of output.
> 
> That crash loop is easy enough to fix to ignore unsupported outputs;
> however, my thought here is a simply defense in depth fixup, especially
> since the kernel patch is quite trivial.

Got it, thanks for explaining.

My concern is that if we are expected to always report channel counts
we're signing up for a major whack-a-mole with the existing drivers.
Most drivers don't implement it. The networking stack does report
the number of queues the device asked for via rtnetlink:

ip -j -d li show dev $ifc | jq '.[].num_rx_queues'

but in your case I'd personally lean towards user space fix.