On 5/21/25 3:31 PM, Keith Busch wrote:
From: Keith Busch <kbusch@xxxxxxxxxx>
I was never happy with previous block copy offload attempts, so I had to
take a stab at it. And I was recently asked to take a look at this, so
here goes.
Some key implementation differences from previous approaches:
1. Only one bio is needed to describe a copy request, so no plugging
or dispatch tricks required. Like read and write requests, these
can be artbitrarily large and will be split as needed based on the
request_queue's limits. The bio's are mergeable with other copy
commands on adjacent destination sectors.
2. You can describe as many source sectors as you want in a vector in
a single bio. This aligns with the nvme protocol's Copy implementation,
which can be used to efficiently defragment scattered blocks into a
contiguous destination with a single command.
Oh, and the nvme-target support was included with this patchset too, so
there's a purely in-kernel way to test out the code paths if you don't
have otherwise capable hardware. I also used qemu since that nvme device
supports copy offload too.
Before any copy offloading code is merged in the upstream kernel, a plan
should be presented for how this partial implementation will evolve into
a generic solution. As Hannes already pointed out, support for
copying between block devices is missing. SCSI support is missing.
Device mapper support is missing. What is the plan for evolving this
patch series into a generic solution? Is it even possible to evolve this
patch series into a generic solution?
Thanks,
Bart.
