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

[Jon Kohler]

> On May 4, 2026, at 9:06 PM, Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
> 
> On Tue, 5 May 2026 00:59:40 +0000 Jon Kohler wrote:
>>> On May 4, 2026, at 7:49 PM, Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
>>>> e1000e hardware supports a single RX/TX queue pair, add basic support
>>>> for ethtool -l (i.e. get_channels), so that callers indeed see a single
>>>> queue.  
>>> 
>>> Why? Isn't EOPNOTSUP from ethtool -l implicitly saying that there's
>>> only one queue?  
>> 
>> 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.