On 21/05/24 09:06AM, Hannes Reinecke wrote:
On 5/20/24 12:20, 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.
At present in kernel user of emulation is fabrics.
Signed-off-by: Nitesh Shetty <nj.shetty@xxxxxxxxxxx>
Signed-off-by: Vincent Fu <vincent.fu@xxxxxxxxxxx>
Signed-off-by: Anuj Gupta <anuj20.g@xxxxxxxxxxx>
---
block/blk-lib.c | 223 +++++++++++++++++++++++++++++++++++++++++
include/linux/blkdev.h | 4 +
2 files changed, 227 insertions(+)
Again, I'm not sure if we need this.
After all, copy offload _is_optional, so we need to be prepared to
handle systems where it's not supported. In the end, the caller might
decide to do something else entirely; having an in-kernel emulation
would defeat that.
And with adding an emulation to nullblk we already have an emulation
target to try if people will want to start experimenting.
So I'd rather not have this but rather let the caller deal with the
fact that copy offload is optional.
Unlike previous iteration, blkdev_copy_offload doesn't fallback to emulation
incase offload fails.
This is one more option caller/user can leverage, if for some reason
device copy offload is not supported/optimal.
It is upto to the caller to decide, if it wants to use copy emulation.
Moreover we found this is very useful for fabrics scenario, where this saves
the network bandwidth, by sending offload over the network rather than
read+write(when target doesn't support offload).
Thank you
Nitesh Shetty
