> 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: >>> On May 4, 2026, at 7:49 PM, Jakub Kicinski <[email protected]> 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.
