From: Christoph Hellwig <hch@lst.de>
To: Nilay Shroff <nilay@linux.ibm.com>
Cc: linux-nvme@lists.infradead.org, kbusch@kernel.org, hch@lst.de,
hare@suse.de, sagi@grimberg.me, chaitanyak@nvidia.com,
gjoyce@linux.ibm.com
Subject: Re: [RFC PATCH 1/4] nvme-tcp: optionally limit I/O queue count based on NIC queues
Date: Fri, 24 Apr 2026 15:46:20 +0200 [thread overview]
Message-ID: <20260424134620.GA17351@lst.de> (raw)
In-Reply-To: <20260420115716.3071293-2-nilay@linux.ibm.com>
> In such configurations, limiting the number of NVMe-TCP I/O queues to
> the number of NIC hardware queues can improve performance by reducing
> contention and improving locality. Aligning NVMe-TCP worker threads with
> NIC queue topology may also help reduce tail latency.
Yes, this sounds useful.
>
> Add a new transport option "match_hw_queues" to allow users to
> optionally limit the number of NVMe-TCP I/O queues to the number of NIC
> TX/RX queues. When enabled, the number of I/O queues is set to:
>
> min(num_online_cpus, num_nic_queues)
>
> This behavior is opt-in and does not change existing defaults.
Any good reason for that? For PCI and RDMA we try to do the right
thing by default.
> +static struct net_device *nvme_tcp_get_netdev(struct nvme_ctrl *ctrl)
> +{
> + struct net_device *dev = NULL;
> +
> + if (ctrl->opts->mask & NVMF_OPT_HOST_IFACE)
> + dev = dev_get_by_name(&init_net, ctrl->opts->host_iface);
Return early here instead of the giant indentation for the new options.
> + else {
> + struct nvme_tcp_ctrl *tctrl = to_tcp_ctrl(ctrl);
> +
> + if (tctrl->addr.ss_family == AF_INET) {
And then split each address family into a helper. And to me those
look like something that should be in net/.
> +
> +/*
> + * Returns number of active NIC queues (min of TX/RX), or 0 if device cannot
> + * be determined.
> + */
> +static int nvme_tcp_get_netdev_current_queue_count(struct nvme_ctrl *ctrl)
drop _current to make this a bit more readable?
> @@ -2144,6 +2243,24 @@ static int nvme_tcp_alloc_io_queues(struct nvme_ctrl *ctrl)
> unsigned int nr_io_queues;
> int ret;
>
> + if (!(ctrl->opts->mask & NVMF_OPT_NR_IO_QUEUES) &&
> + (ctrl->opts->mask & NVMF_OPT_MATCH_HW_QUEUES)) {
The more readable formatting would be:
if (!(ctrl->opts->mask & NVMF_OPT_NR_IO_QUEUES) &&
(ctrl->opts->mask & NVMF_OPT_MATCH_HW_QUEUES)) {
> + int nr_hw_queues;
> +
> + nr_hw_queues = nvme_tcp_get_netdev_current_queue_count(ctrl);
> + if (nr_hw_queues <= 0)
> + goto init_queue;
> +
> + ctrl->opts->nr_io_queues = min(nr_hw_queues, num_online_cpus());
> +
> + if (ctrl->opts->nr_io_queues < num_online_cpus())
> + dev_info(ctrl->device,
> + "limiting I/O queues to %u (NIC queues %d, CPUs %u)\n",
> + ctrl->opts->nr_io_queues, nr_hw_queues,
> + num_online_cpus());
> + }
And splitting this into a helper would help keeping the flow sane.
next prev parent reply other threads:[~2026-04-24 13:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-20 11:49 [RFC PATCH 0/4] nvme-tcp: NIC topology aware I/O queue scaling and queue info export Nilay Shroff
2026-04-20 11:49 ` [RFC PATCH 1/4] nvme-tcp: optionally limit I/O queue count based on NIC queues Nilay Shroff
2026-04-24 13:46 ` Christoph Hellwig [this message]
2026-04-27 7:37 ` Nilay Shroff
2026-04-24 22:10 ` Sagi Grimberg
2026-04-27 11:57 ` Nilay Shroff
2026-04-20 11:49 ` [RFC PATCH 2/4] nvme-tcp: add a diagnostic message when NIC queues are underutilized Nilay Shroff
2026-04-24 22:15 ` Sagi Grimberg
2026-04-27 12:14 ` Nilay Shroff
2026-04-20 11:49 ` [RFC PATCH 3/4] nvme: add debugfs helpers for NVMe drivers Nilay Shroff
2026-04-20 11:49 ` [RFC PATCH 4/4] nvme: expose queue information via debugfs Nilay Shroff
2026-04-24 22:23 ` Sagi Grimberg
2026-04-27 12:12 ` Nilay Shroff
2026-04-22 11:10 ` [RFC PATCH 0/4] nvme-tcp: NIC topology aware I/O queue scaling and queue info export Hannes Reinecke
2026-04-24 22:30 ` Sagi Grimberg
2026-04-27 12:11 ` Nilay Shroff
2026-04-27 6:13 ` 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=20260424134620.GA17351@lst.de \
--to=hch@lst.de \
--cc=chaitanyak@nvidia.com \
--cc=gjoyce@linux.ibm.com \
--cc=hare@suse.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=nilay@linux.ibm.com \
--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.