On Sat, Aug 12, 2023 at 3:42 AM Bart Van Assche [off-list ref] wrote:

On 8/11/23 03:52, Nitesh Shetty wrote:

quoted

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.

[ ... ]

quoted

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