Messages in this thread | | | Date | Mon, 7 Dec 2020 09:16:31 +0100 | From | "" <> | Subject | Re: [RFC PATCH v2 0/2] add simple copy support |
| |
On 07.12.2020 08:06, Damien Le Moal wrote: >On 2020/12/07 16:46, javier.gonz@samsung.com 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. >
| |