All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Jon Kohler <jon@nutanix.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	"intel-wired-lan@lists.osuosl.org"
	<intel-wired-lan@lists.osuosl.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Intel-wired-lan] [PATCH net-next] e1000e: ethtool: add get_channels support
Date: Mon, 4 May 2026 18:06:56 -0700	[thread overview]
Message-ID: <20260504180656.62539d96@kernel.org> (raw)
In-Reply-To: <6F0C5872-0388-47AF-8CD9-1D116EA13224@nutanix.com>

On Tue, 5 May 2026 00:59:40 +0000 Jon Kohler wrote:
> > On May 4, 2026, at 7:49 PM, Jakub Kicinski <kuba@kernel.org> 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.

WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Jon Kohler <jon@nutanix.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	"intel-wired-lan@lists.osuosl.org"
	<intel-wired-lan@lists.osuosl.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next] e1000e: ethtool: add get_channels support
Date: Mon, 4 May 2026 18:06:56 -0700	[thread overview]
Message-ID: <20260504180656.62539d96@kernel.org> (raw)
In-Reply-To: <6F0C5872-0388-47AF-8CD9-1D116EA13224@nutanix.com>

On Tue, 5 May 2026 00:59:40 +0000 Jon Kohler wrote:
> > On May 4, 2026, at 7:49 PM, Jakub Kicinski <kuba@kernel.org> 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.

  reply	other threads:[~2026-05-05  1:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-04 15:48 [Intel-wired-lan] [PATCH net-next] e1000e: ethtool: add get_channels support Jon Kohler
2026-05-04 15:48 ` Jon Kohler
2026-05-04 17:41 ` [Intel-wired-lan] " Joe Damato
2026-05-04 17:41   ` Joe Damato
2026-05-04 23:49 ` [Intel-wired-lan] " Jakub Kicinski
2026-05-04 23:49   ` Jakub Kicinski
2026-05-05  0:59   ` [Intel-wired-lan] " Jon Kohler
2026-05-05  0:59     ` Jon Kohler
2026-05-05  1:06     ` Jakub Kicinski [this message]
2026-05-05  1:06       ` Jakub Kicinski
2026-05-05  1:12       ` [Intel-wired-lan] " Jon Kohler
2026-05-05  1:12         ` Jon Kohler
2026-05-05  1:26         ` [Intel-wired-lan] " Jakub Kicinski
2026-05-05  1:26           ` Jakub Kicinski
2026-05-07 23:49           ` [Intel-wired-lan] " Jacob Keller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260504180656.62539d96@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jon@nutanix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.