From: Jakub Kicinski <kuba@kernel.org>
To: "Nambiar, Amritha" <amritha.nambiar@intel.com>
Cc: <netdev@vger.kernel.org>, <pabeni@redhat.com>,
<sridhar.samudrala@intel.com>
Subject: Re: [net-next PATCH v8 02/10] net: Add queue and napi association
Date: Tue, 21 Nov 2023 14:22:07 -0800 [thread overview]
Message-ID: <20231121142207.18ed9f6a@kernel.org> (raw)
In-Reply-To: <68d2b08c-27ae-498e-9ce9-09e88796cd35@intel.com>
On Tue, 21 Nov 2023 13:26:27 -0800 Nambiar, Amritha wrote:
> So, currently, 'ethtool --show-channels' and 'ps -aef | grep napi' would
> list all the queues and NAPIs if the device is DOWN. I think what you
> are pointing at is:
> <ifdown and ./get-queues> should show something similar to <ethtool -L
> eth0 combined 0 (0 is not valid... but almost to that effect) and
> ./get-queues>.
>
> But, 'ethtool -L' actually deletes the queues vs 'device DOWN' which
> only disables or makes the queues inactive.
>
> Maybe as a follow-up patch, would it be better to have an additional
> parameter called 'state' for 'queues-get' and 'napi-get' that indicates
> the queues or NAPIs as active/inactive. The queue/NAPI state would be
> inherited from the device state. This way we can still list the
> queues/NAPIs when the device is down, set/update parameter
> configurations and then bring UP the device (in case where we stop
> traffic and tune parameters).
>
> Also, if in future, we have the interface to tune parameters per-queue
> without full reset (of all queues or the device itself, as the hardware
> supports this), the 'state' would report this for specific queue as
> active/inactive. Maybe:
> 'queue-set' can set 'state = active' for a single queue '{"ifindex": 12,
> "id": 0, "type": 0}' and start a queue.
To reiterate - the thing I find odd about the current situation is that
we hide the queues if they get disabled by lowering ethtool -L, but we
don't hide them when the entire interface is down. When the entire
interface is down there should be no queues, right?
Differently put - what logic that'd make sense to the user do we apply
when trying to decide if the queue is visible? < real_num_queues is
an implementation detail.
We can list all the queues, always, too. No preference. I just want to
make sure that the rules are clear and not very dependent on current
implementation and not different driver to driver.
next prev parent reply other threads:[~2023-11-21 22:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-17 1:16 [net-next PATCH v8 00/10] Introduce queue and NAPI support in netdev-genl (Was: Introduce NAPI queues support) Amritha Nambiar
2023-11-17 1:16 ` [net-next PATCH v8 01/10] netdev-genl: spec: Extend netdev netlink spec in YAML for queue Amritha Nambiar
2023-11-17 1:16 ` [net-next PATCH v8 02/10] net: Add queue and napi association Amritha Nambiar
2023-11-20 23:54 ` Jakub Kicinski
2023-11-21 21:26 ` Nambiar, Amritha
2023-11-21 22:22 ` Jakub Kicinski [this message]
2023-11-22 0:08 ` Nambiar, Amritha
2023-11-22 1:15 ` Jakub Kicinski
2023-11-22 21:28 ` Nambiar, Amritha
2023-11-22 22:00 ` Jakub Kicinski
2023-11-23 0:56 ` Nambiar, Amritha
2023-11-17 1:16 ` [net-next PATCH v8 03/10] ice: Add support in the driver for associating queue with napi Amritha Nambiar
2023-11-17 1:16 ` [net-next PATCH v8 04/10] netdev-genl: Add netlink framework functions for queue Amritha Nambiar
2023-11-17 1:17 ` [net-next PATCH v8 05/10] netdev-genl: spec: Extend netdev netlink spec in YAML for NAPI Amritha Nambiar
2023-11-17 1:17 ` [net-next PATCH v8 06/10] netdev-genl: Add netlink framework functions for napi Amritha Nambiar
2023-11-17 1:17 ` [net-next PATCH v8 07/10] netdev-genl: spec: Add irq in netdev netlink YAML spec Amritha Nambiar
2023-11-17 1:17 ` [net-next PATCH v8 08/10] net: Add NAPI IRQ support Amritha Nambiar
2023-11-17 1:17 ` [net-next PATCH v8 09/10] netdev-genl: spec: Add PID in netdev netlink YAML spec Amritha Nambiar
2023-11-17 1:17 ` [net-next PATCH v8 10/10] netdev-genl: Add PID for the NAPI thread Amritha Nambiar
2023-11-20 23:56 ` [PATCH 11/10] eth: bnxt: link NAPI instances to queues and IRQs Jakub Kicinski
2023-11-21 21:31 ` Nambiar, Amritha
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=20231121142207.18ed9f6a@kernel.org \
--to=kuba@kernel.org \
--cc=amritha.nambiar@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sridhar.samudrala@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).