Re: [PATCH v20 02/12] Add infrastructure for copy offload in block and request layer.

[Bart Van Assche]

On 6/6/24 01:28, Nitesh Shetty wrote:
> On 04/06/24 04:44AM, Bart Van Assche wrote:
> > On 6/3/24 21:40, Christoph Hellwig wrote:
> > > There is no requirement to process them synchronously, there is just
> > > a requirement to preserve the order.  Note that my suggestion a few
> > > arounds ago also included a copy id to match them up.  If we don't
> > > need that I'm happy to leave it away.  If need it it to make stacking
> > > drivers' lifes easier that suggestion still stands.
> >
> > Including an ID in REQ_OP_COPY_DST and REQ_OP_COPY_SRC operations sounds
> > much better to me than abusing the merge infrastructure for combining
> > these two operations into a single request. With the ID-based approach
> > stacking drivers are allowed to process copy bios asynchronously and it
> > is no longer necessary to activate merging for copy operations if
> > merging is disabled (QUEUE_FLAG_NOMERGES).
> Single request, with bio merging approach:
> The current approach is to send a single request to driver,
> which contains both destination and source information inside separate bios.
> Do you have any different approach in mind ?

No. I did not propose to change how copy offload requests are sent to block
drivers (other than stacking drivers).

> If we want to proceed with this single request based approach,
> we need to merge the destination request with source BIOs at some point.
> a. We chose to do it via plug approach.
> b. Alternative I see is scheduler merging, but here we need some way to
> hold the request which has destination info, until source bio is also
> submitted.
> c. Is there any other way, which I am missing here ?

There are already exceptions in blk_mq_submit_bio() for zoned writes and for
flush bios. Another exception could be added for REQ_OP_COPY_* bios. I'm not
claiming that this is the best possible alternative. I'm only mentioning this
to show that there are alternatives.

> Copy ID approach:
> We see 3 possibilities here:
> 1. No merging: If we include copy-id in src and dst bio, the bio's will get
> submitted separately and reach to the driver as separate requests.
> How do we plan to form a copy command in driver ?
> 2. Merging BIOs:
> At some point we need to match the src bio with the dst bio and send this
> information together to the driver. The current implementation.
> This still does not solve the asynchronous submission problem, mentioned
> above.
> 3. Chaining BIOs:
> This won't work with stacked devices as there will be cloning, and hence
> chain won't be maintained.

I prefer option (2). Option (1) could result in a deadlock because the source
and destination bio both would have to be converted into a request before
these are sent to a request-based driver.

Thanks,

Bart.