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

[Jacob Keller]

On 5/4/2026 6:26 PM, Jakub Kicinski wrote:
> On Tue, 5 May 2026 01:12:29 +0000 Jon Kohler wrote:
>>> 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:  
>>  [...]  
>>  [...]  
>>  [...]  
>>>>
>>>> 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.

Yea, unless we wanted to modify the core ethtool logic so that a driver
without .get_channels would report a single queue.. but I don't know if
that's very accurate.

Still, I think in this case it makes sense to just fix the userspace to
handle EOPNOTSUPP instead of assuming it will be available.

Thanks,
Jake