From: Chuck Lever <cel@kernel.org>
To: Anna Schumaker <anna@kernel.org>
Cc: Trond Myklebust <trond.myklebust@hammerspace.com>,
<linux-nfs@vger.kernel.org>, <linux-rdma@vger.kernel.org>,
Chuck Lever <chuck.lever@oracle.com>
Subject: [PATCH v3 0/7] Fix various races in xprtrdma
Date: Fri, 6 Mar 2026 16:56:21 -0500 [thread overview]
Message-ID: <20260306215620.3668-9-cel@kernel.org> (raw)
From: Chuck Lever <chuck.lever@oracle.com>
Since commit b326df4a8ec6 ("NFS: enable nconnect for RDMA"), the
nconnect mount option has been enabled on proto=rdma NFS mount
points. Utilizing this option increases the IOPS throughput that
an NFS mount point is capable of.
To test some ongoing NFS server performance scalability work, I've
started to enable nconnect while testing. I've found that, as well
as enabling much better utilization of fast network fabrics, it
surfaces some subtle race conditions that are well-buried when there
is only a single QP.
This series addresses a few bugs and makes some performance
scalability enhancements to make nconnect with NFS/RDMA even better.
Base commit: 11439c4635edd669ae435eec308f4ab8a0804808
---
Changes since v2:
- Drop Eric's patch -- should already be applied
- Fix a bug with frwr_map's tail boundary check
Chuck Lever (7):
xprtrdma: Close sendctx get/put race that can block a transport
xprtrdma: Avoid 250 ms delay on backlog wakeup
xprtrdma: Close lost-wakeup race in xprt_rdma_alloc_slot
xprtrdma: Decouple frwr_wp_create from frwr_map
xprtrdma: Replace rpcrdma_mr_seg with xdr_buf cursor
xprtrdma: Scale receive batch size with credit window
xprtrdma: Post receive buffers after RPC completion
include/linux/sunrpc/xprt.h | 2 +
include/trace/events/rpcrdma.h | 28 ++---
net/sunrpc/xprt.c | 16 +++
net/sunrpc/xprtrdma/frwr_ops.c | 177 ++++++++++++++++++++++++++------
net/sunrpc/xprtrdma/rpc_rdma.c | 177 ++++++++++++--------------------
net/sunrpc/xprtrdma/transport.c | 17 ++-
net/sunrpc/xprtrdma/verbs.c | 19 +++-
net/sunrpc/xprtrdma/xprt_rdma.h | 43 +++++---
8 files changed, 305 insertions(+), 174 deletions(-)
--
2.53.0
next reply other threads:[~2026-03-06 21:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-06 21:56 Chuck Lever [this message]
2026-03-06 21:56 ` [PATCH v3 1/7] xprtrdma: Close sendctx get/put race that can block a transport Chuck Lever
2026-03-06 21:56 ` [PATCH v3 2/7] xprtrdma: Avoid 250 ms delay on backlog wakeup Chuck Lever
2026-03-06 21:56 ` [PATCH v3 3/7] xprtrdma: Close lost-wakeup race in xprt_rdma_alloc_slot Chuck Lever
2026-03-06 21:56 ` [PATCH v3 4/7] xprtrdma: Decouple frwr_wp_create from frwr_map Chuck Lever
2026-03-06 21:56 ` [PATCH v3 5/7] xprtrdma: Replace rpcrdma_mr_seg with xdr_buf cursor Chuck Lever
2026-03-06 21:56 ` [PATCH v3 6/7] xprtrdma: Scale receive batch size with credit window Chuck Lever
2026-03-06 21:56 ` [PATCH v3 7/7] xprtrdma: Post receive buffers after RPC completion Chuck Lever
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=20260306215620.3668-9-cel@kernel.org \
--to=cel@kernel.org \
--cc=anna@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=trond.myklebust@hammerspace.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