From: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-nvme@lists.infradead.org, Christoph Hellwig <hch@lst.de>,
Nitesh Shetty <nj.shetty@samsung.com>
Subject: Re: [PATCH 00/12] Block storage copy offloading
Date: Fri, 22 May 2026 21:00:04 +0900 [thread overview]
Message-ID: <ahBD9fRrPDuoB2cj@shinmob> (raw)
In-Reply-To: <20260424224201.1949243-1-bvanassche@acm.org>
On Apr 24, 2026 / 15:41, Bart Van Assche wrote:
> Hi Jens,
>
> This patch series implements a new approach for copy offloading. Compared to
> Nitesh' approach, the differences are as follows:
> - Two new limits have been introduced representing the maximum number of source
> and destination ranges. Support for multiple source ranges for the NVMe Copy
> command has been added.
> - The blkdev_copy_offload() function can now submit multiple copy offload
> commands instead of only one.
> - The implementation no longer depends on block layer plugging.
>
> This patch series includes copy offloading support for the Linux kernel block
> layer core, the device mapper core, the null_blk and the NVMe and nvmet drivers.
> Support for the scsi_debug and SCSI core will follow later.
>
> Test scripts are available here:
> https://github.com/bvanassche/blktests/tree/copy-offloading
>
> See also Bart Van Assche, [LSF/MM/BPF TOPIC] Block storage copy offloading,
> January 2026
> (https://lore.kernel.org/all/0cfe6fe2-3865-4dc2-92a7-74b1240f7b63@acm.org/).
>
> See also Nitesh Shetty, Implement copy offload support, May 2024
> (https://lore.kernel.org/linux-block/20240520102033.9361-1-nj.shetty@samsung.com/).
FYI, blktests CI trial run detected that this patch series triggers nvme/018
failure. I manually applied this series on top of the v7.1-rc4 kernel and
observed the failure is recreated in stable manner.
nvme/018 (tr=loop) (unit test NVMe-oF out of range access on a file backend) [failed]
runtime 1.208s ... 1.189s
--- tests/nvme/018.out 2025-04-22 13:13:27.738873155 +0900
+++ /home/shin/Blktests/blktests/results/nodev_tr_loop/nvme/018.out.bad 2026-05-22 20:57:31.060000000 +0900
@@ -1,3 +1,4 @@
Running nvme/018
+ERROR: nvme read for out of range LBA was not rejected
disconnected 1 controller(s)
Test complete
next prev parent reply other threads:[~2026-05-22 12:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-24 22:41 [PATCH 00/12] Block storage copy offloading Bart Van Assche
2026-04-24 22:41 ` [PATCH 01/12] block: Introduce queue limits for " Bart Van Assche
2026-04-24 22:41 ` [PATCH 02/12] block: Add the REQ_OP_COPY_{SRC,DST} operations Bart Van Assche
2026-04-24 22:41 ` [PATCH 03/12] block: Introduce blkdev_copy_offload() Bart Van Assche
2026-04-24 22:41 ` [PATCH 04/12] block: Add an onloaded copy implementation Bart Van Assche
2026-04-24 22:41 ` [PATCH 05/12] block: Introduce accessor functions for copy offload bios Bart Van Assche
2026-04-24 22:41 ` [PATCH 06/12] fs/read_write: Generalize generic_copy_file_checks() Bart Van Assche
2026-04-24 22:41 ` [PATCH 07/12] fs, block: Add copy_file_range() support for block devices Bart Van Assche
2026-04-24 22:41 ` [PATCH 08/12] nvme: Add copy offloading support Bart Van Assche
2026-04-24 22:41 ` [PATCH 09/12] nvmet: Support the Copy command Bart Van Assche
2026-04-24 22:41 ` [PATCH 10/12] dm: Add support for copy offloading Bart Van Assche
2026-04-24 22:42 ` [PATCH 11/12] dm-linear: Enable " Bart Van Assche
2026-04-24 22:42 ` [PATCH 12/12] null_blk: Add support for REQ_OP_COPY_* Bart Van Assche
2026-05-22 12:00 ` Shin'ichiro Kawasaki [this message]
2026-05-22 16:22 ` [PATCH 00/12] Block storage copy offloading Bart Van Assche
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=ahBD9fRrPDuoB2cj@shinmob \
--to=shinichiro.kawasaki@wdc.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=nj.shetty@samsung.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.