From: Yoav Cohen <yoav@nvidia.com>
To: Ming Lei <ming.lei@redhat.com>, Jens Axboe <axboe@kernel.dk>,
<linux-block@vger.kernel.org>, <csander@purestorage.com>
Cc: <jholzman@nvidia.com>, <omril@nvidia.com>, Yoav Cohen <yoav@nvidia.com>
Subject: [PATCH v2 0/2] ublk: honor rq_affinity on request completion
Date: Tue, 6 Oct 2026 22:03:46 +0300 [thread overview]
Message-ID: <20261006190348.85094-1-yoav@nvidia.com> (raw)
ublk ends successfully completed requests inline on the server thread,
so rq_affinity never redirects completion work back to the submitting
CPU the way it does for NVMe, SCSI, virtio-blk, loop, nbd and rnbd.
Patch 1 fixes that and adds a feature flag so servers can detect
support. Patch 2 adds a selftest for it.
v2, addressing Ming Lei's review of v1:
- v1 only redirected the classic-copy-mode successful-read completion;
every write, flush/discard, error, and zero-copy/user-copy/
auto-buf-reg/shmem-zc I/O still completed inline as before, so
rq_affinity had no effect for most traffic. ublk_end_rq() now
re-derives which completion path __ublk_complete_rq() took from
@req/@io state, so every outcome goes through
blk_mq_complete_request_remote().
- v1 ran the new completion path unconditionally on any patched
kernel. v2 adds UBLK_F_SUPPORT_RQ_AFFINITY, which a server must
request at ADD_DEV time; without it, behavior is unchanged.
With an SPDK-style polling user-space block server at queue depth 96,
rq_affinity=2 gives 7-8% higher IOPS than today's always-inline
completion by offloading a saturated server CPU; rq_affinity=0 keeps
the old behavior for anyone who wants to opt out.
Yoav Cohen (2):
ublk: honor rq_affinity on request completion
selftests: ublk: add rq_affinity test
drivers/block/ublk_drv.c | 98 ++++++++++++++-----
include/uapi/linux/ublk_cmd.h | 8 ++
tools/testing/selftests/ublk/Makefile | 1 +
tools/testing/selftests/ublk/kublk.c | 6 +-
.../testing/selftests/ublk/test_generic_18.sh | 42 ++++++++
5 files changed, 132 insertions(+), 23 deletions(-)
create mode 100755 tools/testing/selftests/ublk/test_generic_18.sh
--
2.50.1 (Apple Git-155)
next reply other threads:[~2026-10-06 19:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 19:03 Yoav Cohen [this message]
2026-10-06 19:03 ` [PATCH v2 1/2] ublk: honor rq_affinity on request completion Yoav Cohen
2026-10-06 21:53 ` Caleb Sander Mateos
2026-10-09 13:43 ` Ming Lei
2026-10-09 15:25 ` Caleb Sander Mateos
2026-10-09 14:04 ` Ming Lei
2026-10-06 19:03 ` [PATCH v2 2/2] selftests: ublk: add rq_affinity test Yoav Cohen
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=20261006190348.85094-1-yoav@nvidia.com \
--to=yoav@nvidia.com \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=jholzman@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=omril@nvidia.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.