archive mirror
 help / color / mirror / Atom feed
From: "Javier González" <>
To: Max Gurtovoy <>
Cc: Chaitanya Kulkarni <>,
	SelvaKumar S <>,,,
	Damien Le Moal <>,,,,,,,,,,,,,
Subject: Re: [RFC PATCH v5 0/4] add simple copy support
Date: Sun, 11 Apr 2021 21:26:41 +0200	[thread overview]
Message-ID: <20210411192641.ya6ntxannk3gjyl5@mpHalley.localdomain> (raw)
In-Reply-To: <>

On 11.04.2021 12:10, Max Gurtovoy wrote:
>On 4/10/2021 9:32 AM, Javier González wrote:
>>>On 10 Apr 2021, at 02.30, Chaitanya Kulkarni <> wrote:
>>>On 4/9/21 17:22, Max Gurtovoy wrote:
>>>>>On 2/19/2021 2:45 PM, SelvaKumar S wrote:
>>>>>This patchset tries to add support for TP4065a ("Simple Copy Command"),
>>>>>v2020.05.04 ("Ratified")
>>>>>The Specification can be found in following link.
>>>>>Simple copy command is a copy offloading operation and is  used to copy
>>>>>multiple contiguous ranges (source_ranges) of LBA's to a single destination
>>>>>LBA within the device reducing traffic between host and device.
>>>>>This implementation doesn't add native copy offload support for stacked
>>>>>devices rather copy offload is done through emulation. Possible use
>>>>>cases are F2FS gc and BTRFS relocation/balance.
>>>>>*blkdev_issue_copy* takes source bdev, no of sources, array of source
>>>>>ranges (in sectors), destination bdev and destination offset(in sectors).
>>>>>If both source and destination block devices are same and copy_offload = 1,
>>>>>then copy is done through native copy offloading. Copy emulation is used
>>>>>in other cases.
>>>>>As SCSI XCOPY can take two different block devices and no of source range is
>>>>>equal to 1, this interface can be extended in future to support SCSI XCOPY.
>>>>Any idea why this TP wasn't designed for copy offload between 2
>>>>different namespaces in the same controller ?
>>>Yes, it was the first attempt so to keep it simple.
>>>Further work is needed to add incremental TP so that we can also do a copy
>>>between the name-spaces of same controller (if we can't already) and to the
>>>namespaces that belongs to the different controller.
>>>>And a simple copy will be the case where the src_nsid == dst_nsid ?
>>>>Also why there are multiple source ranges and only one dst range ? We
>>>>could add a bit to indicate if this range is src or dst..
>>One of the target use cases was ZNS in order to avoid fabric transfers during host GC. You can see how this plays well with several zone ranges and a single zone destination.
>>If we start getting support in Linux through the different past copy offload efforts, I’m sure we can extend this TP in the future.
>But the "copy" command IMO is more general than the ZNS GC case, that 
>can be a private case of copy, isn't it ?

It applies to any namespace type, so yes. I just wanted to give you the
background for the current "simple" scope through one of the use cases
that was in mind.

>We can get a big benefit of offloading the data copy from one ns to 
>another in the same controller and even in different controllers in 
>the same subsystem.


>Do you think the extension should be to "copy" command or to create a 
>new command "x_copy" for copying to different destination ns ?

I believe there is space for extensions to simple copy. But given the
experience with XCOPY, I can imagine that changes will be incremental,
based on very specific use cases.

I think getting support upstream and bringing deployed cases is a very
good start.

Linux-nvme mailing list

  reply	other threads:[~2021-04-11 19:27 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2021-02-19 12:45 ` SelvaKumar S
     [not found]   ` <>
2021-02-19 12:45     ` [RFC PATCH v5 1/4] block: make bio_map_kern() non static SelvaKumar S
     [not found]   ` <>
2021-02-19 12:45     ` [RFC PATCH v5 2/4] block: add simple copy support SelvaKumar S
2021-02-20  4:59       ` Damien Le Moal
2021-04-07 11:32         ` Selva Jove
2021-04-12  0:24           ` Damien Le Moal
2021-04-12 14:34             ` Selva Jove
2021-04-13  0:32               ` Damien Le Moal
2021-04-14  6:58                 ` Selva Jove
     [not found]   ` <>
2021-02-19 12:45     ` [RFC PATCH v5 3/4] nvme: " SelvaKumar S
2021-02-20  3:36       ` Matthew Wilcox
2021-02-22 15:57         ` Selva Jove
     [not found]   ` <>
2021-02-19 12:45     ` [RFC PATCH v5 4/4] dm kcopyd: add simple copy offload support SelvaKumar S
2021-02-20 18:01   ` [RFC PATCH v5 0/4] add simple copy support David Laight
2021-02-20 19:08     ` Matthew Wilcox
2021-02-20 19:19     ` Keith Busch
2021-02-21 23:52   ` Dave Chinner
2021-02-23  9:14     ` Selva Jove
2021-02-22  1:31   ` Ming Lei
2021-02-22  6:52   ` Su Yue
2021-02-23  9:00     ` Selva Jove
2021-04-10  0:21   ` Max Gurtovoy
2021-04-10  0:29     ` Chaitanya Kulkarni
2021-04-10  6:32       ` Javier González
2021-04-11  9:10         ` Max Gurtovoy
2021-04-11 19:26           ` Javier González [this message]
2021-04-13 15:38             ` Max Gurtovoy
2021-04-13 18:25               ` Javier González
2021-04-13 18:36                 ` Chaitanya Kulkarni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210411192641.ya6ntxannk3gjyl5@mpHalley.localdomain \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC PATCH v5 0/4] add simple copy support' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).