Messages in this thread |  | | Date | Mon, 4 May 2026 18:26:35 -0700 | | From | Jakub Kicinski <> | | Subject | Re: [PATCH net-next] e1000e: ethtool: add get_channels support |
| |
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.
|  |