Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: u8o1RURKCvnM57JmVg6h6efxc8XJa67P9q4FAKsEEJFg2f/blNF2iFGfhAxE2yCamIf60Up+XL
 9QVpQgQ0XYiPnqYJDuGJ6/yLLWZzGQdBiNLM9/qg18Irng4D25CuTMSh9K3jrFArh8aoelKI4m
 7YsYmZMD6epPtQAaEWZCHErz6cMDinSo5FWMRnvkSI/yDwUf1A6+XQjBWiXIa/vP3ZbpUmGrTl
 YqpDA3ddyW7h5hD6q5fs8LPh+OKXTsYBfkZJFEeOdKLOFBiZ0tVuC1zr2E8lKdANfH+0miXgLK
 w6Y=
From:   Damien Le Moal <Damien.LeMoal@wdc.com>
To:     "javier.gonz@samsung.com" <javier@javigon.com>
CC:     Keith Busch <kbusch@kernel.org>,
        SelvaKumar S <selvakuma.s1@samsung.com>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
        "axboe@kernel.dk" <axboe@kernel.dk>, "hch@lst.de" <hch@lst.de>,
        "sagi@grimberg.me" <sagi@grimberg.me>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "dm-devel@redhat.com" <dm-devel@redhat.com>,
        "snitzer@redhat.com" <snitzer@redhat.com>,
        "selvajove@gmail.com" <selvajove@gmail.com>,
        "nj.shetty@samsung.com" <nj.shetty@samsung.com>,
        "joshi.k@samsung.com" <joshi.k@samsung.com>,
        "Martin K . Petersen" <martin.petersen@oracle.com>
Subject: Re: [RFC PATCH v2 0/2] add simple copy support
Thread-Topic: [RFC PATCH v2 0/2] add simple copy support
Thread-Index: AQHWyiztcinYLb1afkCNvyh+SmI/oQ==
Date:   Mon, 7 Dec 2020 09:01:39 +0000
Message-ID: <CH2PR04MB6522EF7D29164CE0150B26DFE7CE0@CH2PR04MB6522.namprd04.prod.outlook.com>
References: <CGME20201204094719epcas5p23b3c41223897de3840f92ae3c229cda5@epcas5p2.samsung.com>
 <20201204094659.12732-1-selvakuma.s1@samsung.com>
 <CH2PR04MB6522F1188557C829285ED5E8E7F10@CH2PR04MB6522.namprd04.prod.outlook.com>
 <20201204144003.GA8868@redsun51.ssa.fujisawa.hgst.com>
 <20201207074616.mocdy6m5qgsn6yqg@mpHalley>
 <CH2PR04MB6522623991D84D67B13DDF66E7CE0@CH2PR04MB6522.namprd04.prod.outlook.com>
 <20201207081631.usapwn5jj35c5633@mpHalley>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 08c68f0d-74e6-4332-bd72-08d89a8eb55a
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2020 09:01:39.0605
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vMuLSxANjL2M2HwoEZfSEX2cCCetKSkmvxl7JlvhRK/IpVdIy6ofQgrxUdhUJIwhTE4N/n2Fa6lVhl5GQezeYQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR04MB6569
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2020/12/07 17:16, javier.gonz@samsung.com wrote:=0A=
> On 07.12.2020 08:06, Damien Le Moal wrote:=0A=
>> On 2020/12/07 16:46, javier.gonz@samsung.com wrote:=0A=
>>> On 04.12.2020 23:40, Keith Busch wrote:=0A=
>>>> On Fri, Dec 04, 2020 at 11:25:12AM +0000, Damien Le Moal wrote:=0A=
>>>>> On 2020/12/04 20:02, SelvaKumar S wrote:=0A=
>>>>>> This patchset tries to add support for TP4065a ("Simple Copy Command=
"),=0A=
>>>>>> v2020.05.04 ("Ratified")=0A=
>>>>>>=0A=
>>>>>> The Specification can be found in following link.=0A=
>>>>>> https://nvmexpress.org/wp-content/uploads/NVM-Express-1.4-Ratified-T=
Ps-1.zip=0A=
>>>>>>=0A=
>>>>>> This is an RFC. Looking forward for any feedbacks or other alternate=
=0A=
>>>>>> designs for plumbing simple copy to IO stack.=0A=
>>>>>>=0A=
>>>>>> Simple copy command is a copy offloading operation and is  used to c=
opy=0A=
>>>>>> multiple contiguous ranges (source_ranges) of LBA's to a single dest=
ination=0A=
>>>>>> LBA within the device reducing traffic between host and device.=0A=
>>>>>>=0A=
>>>>>> This implementation accepts destination, no of sources and arrays of=
=0A=
>>>>>> source ranges from application and attach it as payload to the bio a=
nd=0A=
>>>>>> submits to the device.=0A=
>>>>>>=0A=
>>>>>> Following limits are added to queue limits and are exposed in sysfs=
=0A=
>>>>>> to userspace=0A=
>>>>>> 	- *max_copy_sectors* limits the sum of all source_range length=0A=
>>>>>> 	- *max_copy_nr_ranges* limits the number of source ranges=0A=
>>>>>> 	- *max_copy_range_sectors* limit the maximum number of sectors=0A=
>>>>>> 		that can constitute a single source range.=0A=
>>>>>=0A=
>>>>> Same comment as before. I think this is a good start, but for this to=
 be really=0A=
>>>>> useful to users and kernel components alike, this really needs copy e=
mulation=0A=
>>>>> for drives that do not have a native copy feature, similarly to what =
write zeros=0A=
>>>>> handling for instance: if the drive does not have a copy command (sim=
ple copy=0A=
>>>>> for NVMe or XCOPY for scsi), then the block layer should issue read/w=
rite=0A=
>>>>> commands to seamlessly execute the copy. Otherwise, this will only se=
rve a small=0A=
>>>>> niche for users and will not be optimal for FS and DM drivers that co=
uld be=0A=
>>>>> simplified with a generic block layer copy functionality.=0A=
>>>>>=0A=
>>>>> This is my 10 cents though, others may differ about this.=0A=
>>>>=0A=
>>>> Yes, I agree that copy emulation support should be included with the=
=0A=
>>>> hardware enabled solution.=0A=
>>>=0A=
>>> Keith, Damien,=0A=
>>>=0A=
>>> Can we do the block layer emulation with this patchset and then work in=
=0A=
>>> follow-up patchses on (i) the FS interface with F2FS as a first user an=
d=0A=
>>> (ii) other HW accelerations such as XCOPY?=0A=
>>=0A=
>> The initial patchset supporting NVMe simple copy and emulation copy, all=
 under=0A=
>> an API that probably will be similar that of dm-kcopyd will cover all bl=
ock=0A=
>> devices. Other hardware native support for copy functions such as scsi e=
xtended=0A=
>> copy can be added later under the hood without any API changes (or minim=
al changes).=0A=
> =0A=
> Sounds good. That we can do. We will add a new patch for this.=0A=
> =0A=
>>=0A=
>> I am not sure what you mean by "FS interface for F2FS": the block layer =
API for=0A=
>> this copy functionality will be what F2FS (and other FSes) will call. Th=
at is=0A=
>> the interface, no ?=0A=
> =0A=
> Essentially yes.. I mean adding the F2FS logic and potentially some=0A=
> helpers to the block layer to aid GC.=0A=
=0A=
GC is very much special to each FS. SO I do not think adding helpers to the=
=0A=
block layer will have value. We should stick to a pure block copy API for t=
hat=0A=
layer.=0A=
=0A=
> =0A=
>>=0A=
>>> For XCOPY, I believe we need to have a separate discussion as much work=
s=0A=
>>> is already done that we should align to.=0A=
>>=0A=
>> I think Martin (added to this thread) and others have looked into it but=
 I do=0A=
>> not think that anything made it into the kernel yet.=0A=
> =0A=
> Exactly. Looking at some of the code posted through time and recalling=0A=
> the discussions at LSF/MM, seems like there are a number of things we=0A=
> are not addressing here that could be incorporated down the road, such=0A=
> as dedicated syscalls / extensions, multi namespace / device support,=0A=
> etc.=0A=
=0A=
dm-kcopyd interface supports copy between multiple devices. That of course =
would=0A=
not enable NVMe simple copy use, but that makes the interface generic enoug=
h so=0A=
that we should not have any problem with other hardware copy functions.=0A=
=0A=
>>=0A=
> =0A=
=0A=
=0A=
-- =0A=
Damien Le Moal=0A=
Western Digital Research=0A=