On Sat, Aug 12, 2023 at 3:42 AM Bart Van Assche <bvanassche@xxxxxxx> wrote: > > On 8/11/23 03:52, Nitesh Shetty wrote: > > We achieve copy offload by sending 2 bio's with source and destination > > info and merge them to form a request. This request is sent to driver. > > So this design works only for request based storage drivers. > > [ ... ] > > > Overall series supports: > > ======================== > > 1. Driver > > - NVMe Copy command (single NS, TP 4065), including support > > in nvme-target (for block and file back end). > > > > 2. Block layer > > - Block-generic copy (REQ_OP_COPY_DST/SRC), operation with > > interface accommodating two block-devs > > - Merging copy requests in request layer > > - Emulation, for in-kernel user when offload is natively > > absent > > - dm-linear support (for cases not requiring split) > > > > 3. User-interface > > - copy_file_range > > Is this sufficient? The combination of dm-crypt, dm-linear and the NVMe > driver is very common. What is the plan for supporting dm-crypt? Plan is to add offload support for other dm targets as part of subsequent series once current patchset merges, dm targets can use emulation to achieve the same at present. > Shouldn't bio splitting be supported for dm-linear? Handling split is tricky in this case, if we allow splitting, there is no easy way to match/merge different src/dst bio's. Once we have multi range support then we feel at least src bio's can be split. But this series split won't work. Thank you, Nitesh Shetty -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
