On Tue, 2021-05-11 at 00:15 +0000, Chaitanya Kulkarni wrote:
Hi,* Background :------------------------------------------------------------------------Copy offload is a feature that allows file-systems or storage devicesto be instructed to copy files/logical blocks without requiringinvolvement of the local CPU.With reference to the RISC-V summit keynote [1] single threadedperformance is limiting due to Denard scaling and multi-threadedperformance is slowing down due Moore's law limitations. With the riseof SNIA Computation Technical Storage Working Group (TWG) [2],offloading computations to the device or over the fabrics is becomingpopular as there are several solutions available [2]. One of the commonoperation which is popular in the kernel and is not merged yet is Copyoffload over the fabrics or on to the device.* Problem :------------------------------------------------------------------------The original work which is done by Martin is present here [3]. Thelatest work which is posted by Mikulas [4] is not merged yet. These twoapproaches are totally different from each other. Several storagevendors discourage mixing copy offload requests with regular READ/WRITEI/O. Also, the fact that the operation fails if a copy request everneeds to be split as it traverses the stack it has the unfortunateside-effect of preventing copy offload from working in pretty muchevery common deployment configuration out there.* Current state of the work :------------------------------------------------------------------------With [3] being hard to handle arbitrary DM/MD stacking withoutsplitting the command in two, one for copying IN and one for copyingOUT. Which is then demonstrated by the [4] why [3] it is not a suitablecandidate. Also, with [4] there is an unresolved problem with thetwo-command approach about how to handle changes to the DM layoutbetween an IN and OUT operations.* Why Linux Kernel Storage System needs Copy Offload support now ?-----------------------------------------------------------------------With the rise of the SNIA Computational Storage TWG and solutions [2],existing SCSI XCopy support in the protocol, recent advancement in theLinux Kernel File System for Zoned devices (Zonefs [5]), Peer to PeerDMA support in the Linux Kernel mainly for NVMe devices [7] andeventually NVMe Devices and subsystem (NVMe PCIe/NVMeOF) will benefitfrom Copy offload operation.With this background we have significant number of use-cases which arestrong candidates waiting for outstanding Linux Kernel Block Layer CopyOffload support, so that Linux Kernel Storage subsystem can to addresspreviously mentioned problems [1] and allow efficient offloading of thedata related operations. (Such as move/copy etc.)For reference following is the list of the use-cases/candidates waitingfor Copy Offload support :-1. SCSI-attached storage arrays.2. Stacking drivers supporting XCopy DM/MD.3. Computational Storage solutions.7. File systems :- Local, NFS and Zonefs.4. Block devices :- Distributed, local, and Zoned devices.5. Peer to Peer DMA support solutions.6. Potentially NVMe subsystem both NVMe PCIe and NVMeOF.* What we will discuss in the proposed session ?-----------------------------------------------------------------------I'd like to propose a session to go over this topic to understand :-1. What are the blockers for Copy Offload implementation ?2. Discussion about having a file system interface.3. Discussion about having right system call for user-space.4. What is the right way to move this work forward ?5. How can we help to contribute and move this work forward ?* Required Participants :------------------------------------------------------------------------I'd like to invite file system, block layer, and device driversdevelopers to:-1. Share their opinion on the topic.2. Share their experience and any other issues with [4].3. Uncover additional details that are missing from this proposal.Required attendees :-Martin K. PetersenJens AxboeChristoph HellwigBart Van AsscheZach BrownRoland DreierRic WheelerTrond MyklebustMike SnitzerKeith BuschSagi GrimbergHannes ReineckeFrederick KnightMikulas PatockaKeith BuschRegards,Chaitanya
+1 here. I would like to see how this pans out as many differences may be observed from a standards, implementation and operations point of view.
[3] git://git.kernel.org/pub/scm/linux/kernel/git/mkp/linux.git xcopynamespaces-zns-as-go-to-industry-technology/--dm-devel mailing list
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel