From: Keith Busch <kbusch@kernel.org>
To: Surabhi Gogte <sgogte@purestorage.com>
Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
mkhalfella@purestorage.com, randyj@purestorage.com,
adailey@purestorage.com
Subject: Re: [PATCH v4 0/3] nvme-tcp: parallelize I/O setup queue in connect
Date: Tue, 13 Oct 2026 09:33:06 -0600 [thread overview]
Message-ID: <as5PMuAUcVRDgwUr@kbusch-mbp> (raw)
In-Reply-To: <20260922200718.3941465-1-sgogte@purestorage.com>
On Tue, Sep 22, 2026 at 02:07:15PM -0600, Surabhi Gogte wrote:
> Similar to commit 2a8513091d2f ("nvme-rdma: parallelize I/O queue
> allocation and startup"), I/O queue allocation and start steps
> (including authentication) can be parallelized for nvme-tcp as well.
>
> Patch 1 fixes a pre-existing bug: nvme_tcp_alloc_queue() used
> current->nsproxy->net_ns to create sockets during initial connect
> while it used kernel's init_net for reconnect and error recovery
> paths. The fix captures the caller's network namespace at controller
> allocation time.
>
> Patch 2 is a preparatory refactor: it splits the queue-count
> negotiation and TLS PSK checks into helpers so that the individual
> steps can be called directly from nvme_tcp_configure_io_queues(). No
> functional change.
>
> Patch 3 has the async implementation: it fans the per-queue alloc and
> start out over an async domain, serializes the per-cpu queue-count in
> nvme_tcp_set_queue_io_cpu() that can now run concurrently, and uses
> ctrl->net for all socket creation.
>
> Testing on a 64-core host with 64 IO-queues shows nvme-tcp connection
> time reduced from 61ms to 11ms.
Thanks, applied to nvme-7.4.
prev parent reply other threads:[~2026-10-13 15:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 20:07 [PATCH v4 0/3] nvme-tcp: parallelize I/O setup queue in connect Surabhi Gogte
2026-09-22 20:07 ` [PATCH v4 1/3] nvme-tcp: store and use the caller's network namespace Surabhi Gogte
2026-09-22 20:07 ` [PATCH v4 2/3] nvme-tcp: refactor I/O queue setup path Surabhi Gogte
2026-09-22 20:07 ` [PATCH v4 3/3] nvme-tcp: parallelize I/O queue allocation and startup Surabhi Gogte
2026-10-18 12:25 ` Shin'ichiro Kawasaki
2026-10-13 15:33 ` Keith Busch [this message]
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=as5PMuAUcVRDgwUr@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=adailey@purestorage.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mkhalfella@purestorage.com \
--cc=randyj@purestorage.com \
--cc=sagi@grimberg.me \
--cc=sgogte@purestorage.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.