Updated one (points from Keith and Bart) - Given the multitude of things accumulated on this topic, Martin suggested to have a table/matrix. Some of those should go in the initial patchset, and the remaining are to be staged for subsequent work. Here is the attempt to split the stuff into two buckets. Please change if something needs to be changed below. 1. Driver ********* Initial: NVMe Copy command (single NS), including support in nvme-target Subsequent: Multi NS copy, XCopy/Token-based Copy 2. Block layer ************** Initial: - Block-generic copy (REQ_OP_COPY), with interface accommodating two block-devs - Emulation, when offload is natively absent - DM support (at least dm-linear) Subsequent: Integrity and encryption support 3. User-interface ***************** Initial: new ioctl or io_uring opcode 4. In-kernel user ****************** Initial: at least one user - dm-kcopyd user (e.g. dm-clone), or FS requiring GC (F2FS/Btrfs) Subsequent: - copy_file_range On Tue, Nov 16, 2021 at 7:15 PM Javier González <javier@xxxxxxxxxxx> wrote: > > Hi all, > > Thanks for attending the call on Copy Offload yesterday. Here you have > the meeting notes and 2 specific actions before we proceed with another > version of the patchset. > > We will work on a version of the use-case matrix internally and reply > here in the next couple of days. > > Please, add to the notes and the matrix as you see fit. > > Thanks, > Javier > > ---- > > ATTENDEES > > - Adam > - Arnav > - Chaitanya > - Himashu > - Johannes > - Kanchan > - Keith > - Martin > - Mikulas > - Niklas > - Nitesh > - Selva > - Vincent > - Bart > > NOTES > > - MD and DM are hard requirements > - We need support for all the main users of the block layer > - Same problem with crypto and integrity > - Martin would be OK with separating Simple Copy in ZNS and Copy Offload > - Why did Mikulas work not get upstream? > - Timing was an issue > - Use-case was about copying data across VMs > - No HW vendor support > - Hard from a protocol perspective > - At that point, SCSI was still adding support in the spec > - MSFT could not implement extended copy command in the target (destination) device. > - This is what triggered the token-based implementation > - This triggered array vendors to implement support for copy offload as token-based. This allows mixing with normal read / write workloads > - Martin lost the implementation and dropped it > > DIRECTION > > - Keeping the IOCTL interface is an option. It might make sense to move from IOCTL to io_uring opcode > - Martin is happy to do the SCSIpart if the block layer API is upstreamed > - Token-based implementationis the norm. This allows mixing normal read / write workloads to avoid DoS > - This is the direction as opposed to the extended copy command > - It addresses problems when integrating with DM and simplifies command multiplexing a single bio into many > - It simplifies multiple bios > - We should explore Mikulas approach with pointers. > - Use-cases > - ZNS GC > - dm-kcopyd > - file system GC > - fabrics offload to the storage node > - copy_file_range > - It is OK to implement support incrementally, but the interface needs to support all customers of the block layer > - OK to not support specific DMs (e.g., RAID5) > - We should support DM and MD as a framework and the personalities that are needed. Inspiration in integrity > - dm-linear > - dm-crypt and dm-verify are needed for F2FSuse-case in Androd > - Here, we need copy emulation to support encryption without dealing with HW issues and garbage > - User-interface can wait and be carried out on the side > - Maybe it makes sense to start with internal users > - copy_file_range > - F2FS GC, btrfs GC > - User-space should be allowed to do anything and kernel-space can chop the command accordingly > - We need to define the heuristics of the sizes > - User-space should only work on block devices (no other constructs that are protocol-specific) . Export capabilities in sysfs > - Need copy domains to be exposed in sysfs > - We need to start with bdev to bdev in block layer > - Not specific requirement on multi-namespace in NVMe, but it should be extendable > - Plumbing will support all use-cases > - Try to start with one in-kernel consumer > - Emulation is a must > - Needed for failed I/Os > - Expose capabilities so that users can decide > - We can get help from btrfs and F2FS folks > - The use case for GC and for copy are different. We might have to reflect this in the interface, but the internal plumbing should allow both paths to be maintained as a single one. > > ACTIONS > > - [ ] Make a list of use-cases that we want to support in each specification and pick 1-2 examples for MD, DM. Make sure that the interfaces support this > - [ ] Vendors: Ask internally what is the recommended size for copy, if > any > -- Joshi
