Messages in this thread | | | From | "" <> | Date | Mon, 7 Dec 2020 08:46:16 +0100 | Subject | Re: [RFC PATCH v2 0/2] add simple copy support |
| |
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?
For XCOPY, I believe we need to have a separate discussion as much works is already done that we should align to.
| |