Messages in this thread | | | Date | Mon, 11 Sep 2023 12:39:37 +0530 | From | Nitesh Shetty <> | Subject | Re: [PATCH v15 04/12] block: add emulation for copy |
| |
On Fri, Sep 08, 2023 at 08:06:38AM +0200, Hannes Reinecke wrote: > On 9/6/23 18:38, Nitesh Shetty wrote: > > For the devices which does not support copy, copy emulation is added. > > It is required for in-kernel users like fabrics, where file descriptor is > > not available and hence they can't use copy_file_range. > > Copy-emulation is implemented by reading from source into memory and > > writing to the corresponding destination. > > Also emulation can be used, if copy offload fails or partially completes. > > At present in kernel user of emulation is NVMe fabrics. > > > Leave out the last sentence; I really would like to see it enabled for SCSI, > too (we do have copy offload commands for SCSI ...). > Sure, will do that
> And it raises all the questions which have bogged us down right from the > start: where is the point in calling copy offload if copy offload is not > implemented or slower than copying it by hand? > And how can the caller differentiate whether copy offload bring a benefit to > him? > > IOW: wouldn't it be better to return -EOPNOTSUPP if copy offload is not > available?
Present approach treats copy as a background operation and the idea is to maximize the chances of achieving copy by falling back to emulation. Having said that, it should be possible to return -EOPNOTSUPP, in case of offload IO failure or device not supporting offload. We will update this in next version.
Thank you, Nitesh Shetty
| |