[PATCHv10 0/9] write hints with nvme fdp, scsi streams

[Nitesh Shetty]

On 11/11/24 09:45AM, Bart Van Assche wrote:
>On 11/11/24 1:31 AM, Javier Gonzalez wrote:
>>On 08.11.2024 10:51, Bart Van Assche wrote:
>>>On 11/8/24 9:43 AM, Javier Gonzalez wrote:
>>>>If there is an interest, we can re-spin this again...
>>>
>>>I'm interested. Work is ongoing in JEDEC on support for copy offloading
>>>for UFS devices. This work involves standardizing which SCSI copy
>>>offloading features should be supported and which features are not
>>>required. Implementations are expected to be available soon.
>>
>>Do you have any specific blockers on the last series? I know you have
>>left comments in many of the patches already, but I think we are all a
>>bit confused on where we are ATM.
>
>Nobody replied to this question that was raised 4 months ago:
>https://lore.kernel.org/linux-block/4c7f30af-9fbc-4f19-8f48-ad741aa557c4@acm.org/
>
>I think we need to agree about the answer to that question before we can
>continue with implementing copy offloading.
>
Yes, even I feel the same.
Blocker with copy has been how we should plumb things in block layer.
A couple of approaches we tried in the past[1].
Restating for reference,

1.payload based approach:
   a. Based on Mikulas patch, here a common payload is used for both source
     and destination bio. 
   b. Initially we send source bio, upon reaching driver we update payload
     and complete the bio.
   c. Send destination bio, in driver layer we recover the source info
     from the payload and send the copy command to device.

   Drawback:
   Request payload contains IO information rather than data.
   Based on past experience Christoph and Bart suggested not a good way
   forward.
   Alternate suggestion from Christoph was to used separate BIOs for src
   and destination and match them using token/id.
   As Bart pointed, I find it hard how to match when the IO split happens.

2. Plug based approach:
   a. Take a plug, send destination bio, form request and wait for src bio
   b. send source bio, merge with destination bio
   c. Upon release of plug send request down to driver.

   Drawback:
   Doesn't work for stacked devices which has async submission.
   Bart suggested this is not good solution overall.
   Alternate suggestion was to use list based approach.
   But we observed lifetime management problems, especially in
   failure handling.

3. Single bio approach:
   a. Use single bio to represent both src and dst info.
   b. Use abnormal IO handling similar to discard.
   Drawback:
   Christoph pointed out that, this will have issue of payload containing
   information for both IO stack and wire.


I am really torn on how to proceed further ?
-- Nitesh Shetty


[1] https://lore.kernel.org/linux-block/20240624103212.2donuac5apwwqaor@nj.shetty@samsung.com/