All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <tom.leiming@gmail.com>
To: Jens Axboe <axboe@kernel.dk>, linux-block@vger.kernel.org
Cc: Caleb Sander Mateos <csander@purestorage.com>,
	Ming Lei <tom.leiming@gmail.com>
Subject: [PATCH 6/7] Documentation: ublk: address review comments for SHMEM_ZC docs
Date: Thu,  9 Apr 2026 21:30:18 +0800	[thread overview]
Message-ID: <20260409133020.3780098-7-tom.leiming@gmail.com> (raw)
In-Reply-To: <20260409133020.3780098-1-tom.leiming@gmail.com>

- Use "physical pages" instead of "page frame numbers (PFNs)" for
  clarity
- Remove "without any per-I/O overhead" claim from zero-copy
  description
- Add scatter/gather limitation: each I/O's data must be contiguous
  within a single registered buffer

Suggested-by: Caleb Sander Mateos <csander@purestorage.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
 Documentation/block/ublk.rst | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/block/ublk.rst b/Documentation/block/ublk.rst
index a818e09a4b66..c39d111af2d2 100644
--- a/Documentation/block/ublk.rst
+++ b/Documentation/block/ublk.rst
@@ -492,8 +492,8 @@ The ``UBLK_F_SHMEM_ZC`` feature provides an alternative zero-copy path
 that works by sharing physical memory pages between the client application
 and the ublk server. Unlike the io_uring fixed buffer approach above,
 shared memory zero copy does not require io_uring buffer registration
-per I/O — instead, it relies on the kernel matching page frame numbers
-(PFNs) at I/O time. This allows the ublk server to access the shared
+per I/O — instead, it relies on the kernel matching physical pages
+at I/O time. This allows the ublk server to access the shared
 buffer directly, which is unlikely for the io_uring fixed buffer
 approach.
 
@@ -507,8 +507,7 @@ tells the server where the data already lives.
 
 ``UBLK_F_SHMEM_ZC`` can be thought of as a supplement for optimized client
 applications — when the client is willing to allocate I/O buffers from
-shared memory, the entire data path becomes zero-copy without any per-I/O
-overhead.
+shared memory, the entire data path becomes zero-copy.
 
 Use Cases
 ~~~~~~~~~
@@ -584,6 +583,9 @@ Limitations
   the page cache, which allocates its own pages. These kernel-allocated
   pages will never match the registered shared buffer. Only ``O_DIRECT``
   puts the client's buffer pages directly into the block I/O.
+- **Contiguous data only**: each I/O request's data must be contiguous
+  within a single registered buffer. Scatter/gather I/O that spans
+  multiple non-adjacent registered buffers cannot use the zero-copy path.
 
 Control Commands
 ~~~~~~~~~~~~~~~~
-- 
2.53.0


  parent reply	other threads:[~2026-04-09 13:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-09 13:30 [PATCH 0/7] ublk: followup fixes for SHMEM_ZC Ming Lei
2026-04-09 13:30 ` [PATCH 1/7] ublk: widen ublk_shmem_buf_reg.len to __u64 for 4GB buffer support Ming Lei
2026-04-14 18:40   ` Caleb Sander Mateos
2026-04-14 23:49     ` Ming Lei
2026-04-09 13:30 ` [PATCH 2/7] ublk: verify all pages in multi-page bvec fall within registered range Ming Lei
2026-04-09 13:30 ` [PATCH 3/7] ublk: simplify PFN range loop in __ublk_ctrl_reg_buf Ming Lei
2026-04-09 13:30 ` [PATCH 4/7] ublk: replace xarray with IDA for shmem buffer index allocation Ming Lei
2026-04-09 13:30 ` [PATCH 5/7] ublk: allow buffer registration before device is started Ming Lei
2026-04-09 13:30 ` Ming Lei [this message]
2026-04-09 13:30 ` [PATCH 7/7] MAINTAINERS: update ublk driver maintainer email Ming Lei
2026-04-10  1:11 ` [PATCH 0/7] ublk: followup fixes for SHMEM_ZC Jens Axboe
2026-04-10  1:12 ` Jens Axboe

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=20260409133020.3780098-7-tom.leiming@gmail.com \
    --to=tom.leiming@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=csander@purestorage.com \
    --cc=linux-block@vger.kernel.org \
    /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.