[dm-devel] [PATCH 3/7] block: copy offload support infrastructure

Bart Van Assche bvanassche at acm.org
Tue Aug 17 22:06:37 UTC 2021


On 8/17/21 2:53 PM, Douglas Gilbert wrote:
> On 2021-08-17 4:41 p.m., Mikulas Patocka wrote:
>> On Tue, 17 Aug 2021, Bart Van Assche wrote:
>>> On 8/17/21 3:14 AM, SelvaKumar S wrote:
>>>> 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.
>>
>> I once wrote a copy offload implementation that is compatible with device
>> mapper. The copy operation creates two bios (one for reading and one for
>> writing), passes them independently through device mapper and pairs them
>> at the physical device driver.
>>
>> It's here: 
>> http://people.redhat.com/~mpatocka/patches/kernel/xcopy/current
> 
> In my copy solution the read-side and write-side bio pairs share the 
> same storage (i.e. ram) This gets around the need to copy data between 
> the bio_s.
> See:
>     https://sg.danny.cz/sg/sg_v40.html
> in Section 8 on Request sharing. This technique can be efficiently 
> extend to
> source --> destination1,destination2,...      copies.
> 
> Doug Gilbert
> 
>> I verified that it works with iSCSI. Would you be interested in 
>> continuing
>> this work?

Hi Mikulas and Doug,

Yes, I'm interested in continuing Mikulas' work on copy offloading. I 
will take a look at Doug's approach too for sharing buffers between 
read-side and write-side bios. It may take a few months however before I 
can find the time to work on this.

Thanks,

Bart.




More information about the dm-devel mailing list