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 <[email protected]> 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
