From: Andrei-Alexandru Bleortu <me@andrei-z.com>
To: Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
<linux-nvme@lists.infradead.org>
Cc: Andrei-Alexandru Bleortu <me@andrei-z.com>,
<linux-kernel@vger.kernel.org>
Subject: [PATCH 0/1] nvme-rdma: post the command capsule inline when it fits
Date: Thu, 15 Oct 2026 15:48:22 +0300 [thread overview]
Message-ID: <20261015124823.2962700-1-me@andrei-z.com> (raw)
The host posts each 64-byte command capsule by reference, so the HCA
reads it from host memory before it sends the command. This patch
asks for inline data at QP creation and posts capsules that carry no
in-capsule data with IB_SEND_INLINE. The commit message has the
details and the measurements.
The target is left alone. For a read it posts the response capsule in
the same WR chain as the data RDMA Write. In the measured runs, inlining
the response alone made no measurable difference, and inlining both
capsules was about the same as inlining the command alone.
It builds with W=1 on nvme-7.4 without new warnings. I tested it in a
QEMU guest with rdma_rxe on a dummy netdev and nvmet-rdma looped back
to a file-backed namespace. 16 MiB of O_DIRECT writes and reads at
4 KiB and 128 KiB compared equal. The QP got 80 bytes of inline data.
4371 capsules went inline and 4098 by reference, mostly 4 KiB writes,
which carry in-capsule data. With rxe changed to refuse inline data,
QP creation fell back and the data still compared equal. The guest ran
a 7.3-rc4 based kernel. Its drivers/nvme/host/rdma.c is the same as
nvme-7.4's except for one later fix, 909307cea08a ("nvme-rdma: don't
complete a request after a bogus remote invalidation").
I wrote this patch with an LLM coding assistant (Claude Code), which
also drafted the commit message and ran the build and the VM test.
Andrei-Alexandru Bleortu (1):
nvme-rdma: post the command capsule inline when it fits
drivers/nvme/host/rdma.c | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
base-commit: bbca7c312ab25efd0024eb87545c51a76ab2ea39
--
2.56.0
next reply other threads:[~2026-10-15 12:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 12:48 Andrei-Alexandru Bleortu [this message]
2026-10-15 12:48 ` [PATCH 1/1] " Andrei-Alexandru Bleortu
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=20261015124823.2962700-1-me@andrei-z.com \
--to=me@andrei-z.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®