On 13.04.2021 18:38, Max Gurtovoy wrote:
On 4/11/2021 10:26 PM, Javier González wrote:
On 11.04.2021 12:10, Max Gurtovoy wrote:
On 4/10/2021 9:32 AM, Javier González wrote:
On 10 Apr 2021, at 02.30, Chaitanya Kulkarni
<Chaitanya.Kulkarni@xxxxxxx> wrote:
On 4/9/21 17:22, Max Gurtovoy wrote:
On 2/19/2021 2:45 PM, 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
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 doesn't add native copy offload
support for stacked
devices rather copy offload is done through emulation. Possible use
cases are F2FS gc and BTRFS relocation/balance.
*blkdev_issue_copy* takes source bdev, no of sources,
array of source
ranges (in sectors), destination bdev and destination
offset(in sectors).
If both source and destination block devices are same and
copy_offload = 1,
then copy is done through native copy offloading. Copy
emulation is used
in other cases.
As SCSI XCOPY can take two different block devices and no
of source range is
equal to 1, this interface can be extended in future to
support SCSI XCOPY.
Any idea why this TP wasn't designed for copy offload between 2
different namespaces in the same controller ?
Yes, it was the first attempt so to keep it simple.
Further work is needed to add incremental TP so that we can
also do a copy
between the name-spaces of same controller (if we can't
already) and to the
namespaces that belongs to the different controller.
And a simple copy will be the case where the src_nsid == dst_nsid ?
Also why there are multiple source ranges and only one dst range ? We
could add a bit to indicate if this range is src or dst..
One of the target use cases was ZNS in order to avoid fabric
transfers during host GC. You can see how this plays well with
several zone ranges and a single zone destination.
If we start getting support in Linux through the different past
copy offload efforts, I’m sure we can extend this TP in the
future.
But the "copy" command IMO is more general than the ZNS GC case,
that can be a private case of copy, isn't it ?
It applies to any namespace type, so yes. I just wanted to give you the
background for the current "simple" scope through one of the use cases
that was in mind.
We can get a big benefit of offloading the data copy from one ns
to another in the same controller and even in different
controllers in the same subsystem.
Definitely.
Do you think the extension should be to "copy" command or to
create a new command "x_copy" for copying to different destination
ns ?
I believe there is space for extensions to simple copy. But given the
experience with XCOPY, I can imagine that changes will be incremental,
based on very specific use cases.
I think getting support upstream and bringing deployed cases is a very
good start.
Copying data (files) within the controller/subsystem from ns_A to ns_B
using NVMf will reduce network BW and memory BW in the host server.
This feature is well known and the use case is well known.
Definitely.
The question whether we implement it in vendor specific manner of we
add it to the specification.
I prefer adding it to the spec :)
Agree. Let's build up on top of Simple Copy. We can talk about it
offline in the context of the NVMe TWG.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
