Hi Bart,Mikulas,Martin,Douglas,

We will go through your previous work and use this thread as a medium for
further discussion, if we come across issues to be sorted out.

Thank you,
Nitesh Shetty

On Sat, Aug 21, 2021 at 2:48 AM Bart Van Assche [off-list ref] wrote:

On 8/20/21 3:39 AM, Kanchan Joshi wrote:

quoted

Bart, Mikulas

On Tue, Aug 17, 2021 at 10:44 PM Bart Van Assche [off-list ref] wrote:

quoted

On 8/17/21 3:14 AM, SelvaKumar S wrote:

quoted

Introduce REQ_OP_COPY, a no-merge copy offload operation. Create
bio with control information as payload and submit to the device.
Larger copy operation may be divided if necessary by looking at device
limits. REQ_OP_COPY(19) is a write op and takes zone_write_lock when
submitted to zoned device.
Native copy offload is not supported for stacked devices.

Using a single operation for copy-offloading instead of separate
operations for reading and writing is fundamentally incompatible with
the device mapper. I think we need a copy-offloading implementation that
is compatible with the device mapper.

While each read/write command is for a single contiguous range of
device, with simple-copy we get to operate on multiple discontiguous
ranges, with a single command.
That seemed like a good opportunity to reduce control-plane traffic
(compared to read/write operations) as well.

With a separate read-and-write bio approach, each source-range will
spawn at least one read, one write and eventually one SCC command. And
it only gets worse as there could be many such discontiguous ranges (for
GC use-case at least) coming from user-space in a single payload.
Overall sequence will be
- Receive a payload from user-space
- Disassemble into many read-write pair bios at block-layer
- Assemble those (somehow) in NVMe to reduce simple-copy commands
- Send commands to device

We thought payload could be a good way to reduce the
disassembly/assembly work and traffic between block-layer to nvme.
How do you see this tradeoff?  What seems necessary for device-mapper
usecase, appears to be a cost when device-mapper isn't used.
Especially for SCC (since copy is within single ns), device-mappers
may not be too compelling anyway.

Must device-mapper support be a requirement for the initial support atop SCC?
Or do you think it will still be a progress if we finalize the
user-space interface to cover all that is foreseeable.And for
device-mapper compatible transport between block-layer and NVMe - we
do it in the later stage when NVMe too comes up with better copy
capabilities?

Hi Kanchan,

These days there might be more systems that run the device mapper on top
of the NVMe driver or a SCSI driver than systems that do use the device
mapper. It is common practice these days to use dm-crypt on personal
workstations and laptops. LVM (dm-linear) is popular because it is more
flexible than a traditional partition table. Android phones use
dm-verity on top of hardware encryption. In other words, not supporting
the device mapper means that a very large number of use cases is
excluded. So I think supporting the device mapper from the start is
important, even if that means combining individual bios at the bottom of
the storage stack into simple copy commands.

Thanks,

Bart.