Chaitanya, I would like to join the conversation. Thanks, Nitesh On Sun, Feb 6, 2022 at 7:29 PM Javier González <javier@xxxxxxxxxxx> wrote: > > On 27.01.2022 07:14, Chaitanya Kulkarni wrote: > >Hi, > > > >* Background :- > >----------------------------------------------------------------------- > > > >Copy offload is a feature that allows file-systems or storage devices > >to be instructed to copy files/logical blocks without requiring > >involvement of the local CPU. > > > >With reference to the RISC-V summit keynote [1] single threaded > >performance is limiting due to Denard scaling and multi-threaded > >performance is slowing down due Moore's law limitations. With the rise > >of SNIA Computation Technical Storage Working Group (TWG) [2], > >offloading computations to the device or over the fabrics is becoming > >popular as there are several solutions available [2]. One of the common > >operation which is popular in the kernel and is not merged yet is Copy > >offload over the fabrics or on to the device. > > > >* Problem :- > >----------------------------------------------------------------------- > > > >The original work which is done by Martin is present here [3]. The > >latest work which is posted by Mikulas [4] is not merged yet. These two > >approaches are totally different from each other. Several storage > >vendors discourage mixing copy offload requests with regular READ/WRITE > >I/O. Also, the fact that the operation fails if a copy request ever > >needs to be split as it traverses the stack it has the unfortunate > >side-effect of preventing copy offload from working in pretty much > >every common deployment configuration out there. > > > >* Current state of the work :- > >----------------------------------------------------------------------- > > > >With [3] being hard to handle arbitrary DM/MD stacking without > >splitting the command in two, one for copying IN and one for copying > >OUT. Which is then demonstrated by the [4] why [3] it is not a suitable > >candidate. Also, with [4] there is an unresolved problem with the > >two-command approach about how to handle changes to the DM layout > >between an IN and OUT operations. > > > >We have conducted a call with interested people late last year since > >lack of LSFMMM and we would like to share the details with broader > >community members. > > Chaitanya, > > I would also like to join the F2F conversation as a follow up of the > virtual one last year. We will have a first version of the patches > posted in the next few weeks. This will hopefully serve as a good first > step. > > Adding Kanchan to thread too. > > Javier -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
