On 30.09.2021 09:43, Chaitanya Kulkarni wrote:
Javier,
Hi all,
Since we are not going to be able to talk about this at LSF/MM, a few of
us thought about holding a dedicated virtual discussion about Copy
Offload. I believe we can use Chaitanya's thread as a start. Given the
current state of the current patches, I would propose that we focus on
the next step to get the minimal patchset that can go upstream so that
we can build from there.
I agree with having a call as it has been two years I'm trying to have
this discussion.
Before we setup a call, please summarize following here :-
1. Exactly what work has been done so far.
We can categorize that into two sets. First one for XCopy (2014), and
second one for NVMe Copy (2021).
XCOPY set *********
- block-generic copy command (single range, between one
source/destination device)
- ioctl interface for the above
- SCSI plumbing (block-generic to XCOPY conversion)
- device-mapper support: offload copy whenever possible (if IO is not
split while traveling layers of virtual devices)
NVMe-Copy set *************
- block-generic copy command (multiple ranges, between one
source/destination device)
- ioctl interface for the above
- NVMe plumbing (block-generic to NVMe Copy conversion)
- copy-emulation (read + write) in block-layer
- device-mapper support: no offload, rather fall back to copy-emulation
2. What kind of feedback you got.
For NVMe Copy, the major points are - a) add copy-emulation in
block-layer and use that if copy-offload is not natively supported by
device b) user-interface (ioctl) should be extendable for copy across
two devices (one source, one destination) c) device-mapper targets
should support copy-offload, whenever possible
"whenever possible" cases get reduced compared to XCOPY because NVMe
Copy is wit
3. What are the exact blockers/objections.
I think it was device-mapper for XCOPY and remains the same for NVMe
Copy as well. Device-mapper support requires decomposing copy operation
to read and write. While that is not great for efficiency PoV, bigger
concern is to check if we are taking the same route as XCOPY.
From Martin's document (http://mkp.net/pubs/xcopy.pdf), if I got it
right, one the major blocker is having more failure cases than
successful ones. And that did not justify the effort/code to wire up
device mapper. Is that a factor to consider for NVMe Copy (which is
narrower in scope than XCOPY).
4. Potential ways of moving forward.
a) we defer attempt device-mapper support (until NVMe has
support/usecase), and address everything else (reusable user-interface
etc.)
b) we attempt device-mapper support (by moving to composite read+write
communication between block-layer and nvme)
Is this enough in your mind to move forward with a specific agenda? If
we can, I would like to target the meetup in the next 2 weeks.
Thanks,
Javier
