From: Nilay Shroff <nilay@linux.ibm.com>
To: linux-nvme@lists.infradead.org
Cc: dwagner@suse.de, sagi@grimberg.me, hare@suse.de,
kbusch@kernel.org, hch@lst.de, gjoyce@linux.ibm.com,
chaitanyak@nvidia.com, Nilay Shroff <nilay@linux.ibm.com>
Subject: [PATCH v2 0/4] nvme-cli: NIC topology aware I/O queue scaling
Date: Mon, 21 Sep 2026 13:24:58 +0530 [thread overview]
Message-ID: <20260921075511.2108561-1-nilay@linux.ibm.com> (raw)
Hi,
This series is a rework of the earlier patchset[1]. The main
difference is that --nr-io-queues is now calculated in nvme-cli
instead of in the kernel when establishing an NVMe/TCP connection.
This rework is based on the feedback received[2] from the netdev
maintainers.
The original patchset determined the number of NVMe/TCP I/O queues
based on the number of online CPUs and the number of hardware queues
available on the NIC in kernel driver. This series moves that logic
to nvme-cli.
When --nr-io-queues is not explicitly specified, nvme-cli determines
the egress netdev for the NVMe/TCP connection, retrieves its current
hardware queue count, and calculates the default as:
min(nr_hw_queues, num_online_cpus)
If nr_hw_queues cannot be retrieved, or the NIC only supports one
hardware queue, do not calculate nr-io-queues and let the host
determine the value.
The remaining patches from the original series, which expose NVMe/TCP
queue and flow information through debugfs, are still useful for
subsequent CPU/NIC topology tuning. I will send those changes as a
separate patchset.
The two patchsets are independent and can be reviewed and merged
separately.
As usual, comments, feedback, and suggestions are most welcome!
Thanks!
[1] https://lore.kernel.org/all/20260731073918.614014-1-nilay@linux.ibm.com/
[2] https://lore.kernel.org/all/20260807160904.2eb1b3d1@kernel.org/
Changes since v1:
- Added new patch 3/4 for covering unit test cases for
shr_route_get_egress_iface() and shr_netdev_get_hw_queues()
helpers (Daniel Wagner)
- If nr_hw_queues cannot be retrieved, or the NIC only supports
one hardware queue, do not calculate nr-io-queues and let the
host determine the value.
Nilay Shroff (4):
shared/net-util-linux: add support for retrieving egress netdev
shared/net-util-linux: add support for retrieving NIC h/w queues
shared: add more test coverage for net-util
fabrics: determine --nr-io-queues when not explicitly specified
shared/net-util-linux.c | 265 +++++++++++++++++++++++++++++++++++
shared/net-util.h | 32 +++++
shared/tests/test-net-util.c | 117 ++++++++++++++++
src/fabrics.c | 79 ++++++++++-
4 files changed, 490 insertions(+), 3 deletions(-)
--
2.53.0
next reply other threads:[~2026-09-21 7:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 7:54 Nilay Shroff [this message]
2026-09-21 7:54 ` [PATCH v2 1/4] shared/net-util-linux: add support for retrieving egress netdev Nilay Shroff
2026-09-21 7:55 ` [PATCH v2 2/4] shared/net-util-linux: add support for retrieving NIC h/w queues Nilay Shroff
2026-09-21 7:55 ` [PATCH v2 3/4] shared: add more test coverage for net-util Nilay Shroff
2026-09-21 7:55 ` [PATCH v2 4/4] fabrics: determine --nr-io-queues when not explicitly specified Nilay Shroff
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=20260921075511.2108561-1-nilay@linux.ibm.com \
--to=nilay@linux.ibm.com \
--cc=chaitanyak@nvidia.com \
--cc=dwagner@suse.de \
--cc=gjoyce@linux.ibm.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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.