linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Javier González" <javier@javigon.com>
To: Max Gurtovoy <mgurtovoy@nvidia.com>
Cc: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>,
	SelvaKumar S <selvakuma.s1@samsung.com>,
	linux-nvme@lists.infradead.org, axboe@kernel.dk,
	Damien Le Moal <damien.lemoal@wdc.com>,
	kch@kernel.org, sagi@grimberg.me, snitzer@redhat.com,
	selvajove@gmail.com, linux-kernel@vger.kernel.org,
	nj.shetty@samsung.com, linux-block@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, dm-devel@redhat.com,
	joshi.k@samsung.com, kbusch@kernel.org, joshiiitr@gmail.com,
	hch@lst.de
Subject: Re: [RFC PATCH v5 0/4] add simple copy support
Date: Tue, 13 Apr 2021 20:25:58 +0200	[thread overview]
Message-ID: <20210413182558.v2lynge6aleazgbv@mpHalley.localdomain> (raw)
In-Reply-To: <3a52cc06-27ce-96a4-b180-60fc269719ba@nvidia.com>

On 13.04.2021 18:38, Max Gurtovoy wrote:
>
>On 4/11/2021 10:26 PM, Javier González wrote:
>>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 
>>>>><Chaitanya.Kulkarni@wdc.com> 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.
>>>>>>>https://nvmexpress.org/wp-content/uploads/NVM-Express-1.4-Ratified-TPs-1.zip
>>>>>>>
>>>>>>>
>>>>>>>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.
>>
>>Definitely.
>>
>>>
>>>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.
>
>Copying data (files) within the controller/subsystem from ns_A to ns_B 
>using NVMf will reduce network BW and memory BW in the host server.
>
>This feature is well known and the use case is well known.

Definitely.

>
>The question whether we implement it in vendor specific manner of we 
>add it to the specification.
>
>I prefer adding it to the spec :)

Agree. Let's build up on top of Simple Copy. We can talk about it
offline in the context of the NVMe TWG.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

  reply	other threads:[~2021-04-13 18:26 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210219124555epcas5p1334e7c4d64ada5dc4a2ca0feb48c1d44@epcas5p1.samsung.com>
2021-02-19 12:45 ` SelvaKumar S
     [not found]   ` <CGME20210219124559epcas5p41da46f1c248e334953d407a154697903@epcas5p4.samsung.com>
2021-02-19 12:45     ` [RFC PATCH v5 1/4] block: make bio_map_kern() non static SelvaKumar S
     [not found]   ` <CGME20210219124603epcas5p33add0f2c1781b2a4d71bf30c9e1ac647@epcas5p3.samsung.com>
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]   ` <CGME20210219124608epcas5p2a673f9e00c3e7b5352f115497b0e2d98@epcas5p2.samsung.com>
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]   ` <CGME20210219124611epcas5p1c775b63b537e75da161556e375fcf05e@epcas5p1.samsung.com>
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
2021-04-13 15:38             ` Max Gurtovoy
2021-04-13 18:25               ` Javier González [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20210413182558.v2lynge6aleazgbv@mpHalley.localdomain \
    --to=javier@javigon.com \
    --cc=Chaitanya.Kulkarni@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=damien.lemoal@wdc.com \
    --cc=dm-devel@redhat.com \
    --cc=hch@lst.de \
    --cc=joshi.k@samsung.com \
    --cc=joshiiitr@gmail.com \
    --cc=kbusch@kernel.org \
    --cc=kch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=mgurtovoy@nvidia.com \
    --cc=nj.shetty@samsung.com \
    --cc=sagi@grimberg.me \
    --cc=selvajove@gmail.com \
    --cc=selvakuma.s1@samsung.com \
    --cc=snitzer@redhat.com \
    --subject='Re: [RFC PATCH v5 0/4] add simple copy support' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).