[dm-devel] [RFC PATCH 0/2] add simple copy support

[javier.gonz@samsung.com]

On 01.12.2020 11:22, Damien Le Moal wrote:
>+ Mike and DM list
>
>On 2020/12/01 16:12, SelvaKumar S wrote:
>> This patchset tries to add support for TP4065a ("Simple Copy Command"),
>> v2020.05.04 ("Ratified")
>>
>> The Specification can be found in following link.
>> https://nvmexpress.org/wp-content/uploads/NVM-Express-1.4-Ratified-TPs-1.zip
>>
>> This is an RFC. Looking forward for any feedbacks or other alternate
>> designs for plumbing simple copy to IO stack.
>>
>> Simple copy command is a copy offloading operation and is  used to copy
>> multiple contiguous ranges (source_ranges) of LBA's to a single destination
>> LBA within the device reducing traffic between host and device.
>>
>> This implementation accepts destination, no of sources and arrays of
>> source ranges from application and attach it as payload to the bio and
>> submits to the device.
>>
>> Following limits are added to queue limits and are exposed in sysfs
>> to userspace
>> 	- *max_copy_sectors* limits the sum of all source_range length
>> 	- *max_copy_nr_ranges* limits the number of source ranges
>> 	- *max_copy_range_sectors* limit the maximum number of sectors
>> 		that can constitute a single source range.
>
>This is interesting. I think there are several possible use in the kernel in
>various components: FS (btrfs rebalance, f2fs GC, liklely others) and DM at the
>very least.

Totally agree. We have more patches for simple copy, among others work
on F2FS that leverages for GC. We wanted to start with a simple patchset
enabling IOCTL to be an easy to review start. The rest of the patches
will come.


>However, your patches add support only for NVMe devices that have native support
>for simple copy, leaving all other block devices out. That seriously limits the
>use cases and also does not make this solution attractive since any use of it
>would need to be conditional on the underlying drive capabilities. That means
>more code for the file systems or device mapper developers and maintainers, not
>less.

Makes sense.

>
>To avoid this, I would suggest that this code be extended to add emulation for
>drives that do not implement simple copy natively. This would allow this
>interface to work on any block device, including SAS & SATA HDDs and RAID arrays.
>
>The emulation part of this copy service could I think be based on dm-kcopyd. See
>include/linux/dm-kcopyd.h for the interface. The current dm-kcopyd interface
>takes one source and multiple destination, the reverse of simple copy. But it
>would be fairly straightforward to also allow multiple sources and one
>destination. Simple copy native support would accelerate this case, everything
>else using the regular BIO read+write interface. Moving dm-kcopyd from DM
>infrastructure into the block layer as a set a generic block device sector copy
>service would allow its use in more places. And SCSI XCOPY could also be
>integrated in there as a different drive native support command.

Let us look into this. It makes sense.

It seems fair to start support bottom up from NVMe and then extend to
block layer and F2FS (potentially others). At this stage, we were
assuming that all the work that people like Martin, Bart and other have
been doing through the years on XCOPY could be integrated. Emulation can
be a part of this.

How can we move forward to do this in stages?