Re: [RFC PATCH v2 0/2] add simple copy support

[javier.gonz@xxxxxxxxxxx]

On 07.12.2020 08:06, Damien Le Moal wrote:
> On 2020/12/07 16:46, javier.gonz@xxxxxxxxxxx wrote:
> > On 04.12.2020 23:40, Keith Busch wrote:
> > > On Fri, Dec 04, 2020 at 11:25:12AM +0000, Damien Le Moal wrote:
> > > > On 2020/12/04 20:02, 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.
> > > >
> > > > Same comment as before. I think this is a good start, but for this to be really
> > > > useful to users and kernel components alike, this really needs copy emulation
> > > > for drives that do not have a native copy feature, similarly to what write zeros
> > > > handling for instance: if the drive does not have a copy command (simple copy
> > > > for NVMe or XCOPY for scsi), then the block layer should issue read/write
> > > > commands to seamlessly execute the copy. Otherwise, this will only serve a small
> > > > niche for users and will not be optimal for FS and DM drivers that could be
> > > > simplified with a generic block layer copy functionality.
> > > >
> > > > This is my 10 cents though, others may differ about this.
> > >
> > > Yes, I agree that copy emulation support should be included with the
> > > hardware enabled solution.
> >
> > Keith, Damien,
> >
> > Can we do the block layer emulation with this patchset and then work in
> > follow-up patchses on (i) the FS interface with F2FS as a first user and
> > (ii) other HW accelerations such as XCOPY?
>
> The initial patchset supporting NVMe simple copy and emulation copy, all under
> an API that probably will be similar that of dm-kcopyd will cover all block
> devices. Other hardware native support for copy functions such as scsi extended
> copy can be added later under the hood without any API changes (or minimal changes).

Sounds good. That we can do. We will add a new patch for this.

> I am not sure what you mean by "FS interface for F2FS": the block layer API for
> this copy functionality will be what F2FS (and other FSes) will call. That is
> the interface, no ?

Essentially yes.. I mean adding the F2FS logic and potentially some
helpers to the block layer to aid GC.

> > For XCOPY, I believe we need to have a separate discussion as much works
> > is already done that we should align to.
>
> I think Martin (added to this thread) and others have looked into it but I do
> not think that anything made it into the kernel yet.

Exactly. Looking at some of the code posted through time and recalling
the discussions at LSF/MM, seems like there are a number of things we
are not addressing here that could be incorporated down the road, such
as dedicated syscalls / extensions, multi namespace / device support,
etc.
>