Re: [RFC PATCH v5 0/4] add simple copy support

[Javier González]

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.