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: fb+bTgp3khtlTJU1k780w0Mgb/LQlDHmka4017BhxJFw++OKZJvthnX3hi35EvE37Ww4vCURIk
 ldJ+oghszShiUxAMnk/9gD1bTbir/laQpoFEeu+MJgmDH4fNY/OtH2NKrIjYQJDxX8YzQpJG/P
 u5ZnRV9fFWMc4s2BPPdDe0QHlLH6+F8DQaXCJ8es439dbikk9fEP1o9PGARNC1rrNsiUAmeDAv
 o50JQ1l/s+SWUON1XqsYT35E11+uhqdXxnFVgu8zbHngMxTQ3jakD8Ywk1l7Ud5dZXUIpBXh6E
 QLk=
From:   Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
To:     =?iso-8859-1?Q?Javier_Gonz=E1lez?= <javier@javigon.com>
CC:     Hannes Reinecke <hare@suse.de>, Christoph Hellwig <hch@lst.de>,
        SelvaKumar S <selvakuma.s1@samsung.com>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
        "kbusch@kernel.org" <kbusch@kernel.org>,
        "axboe@kernel.dk" <axboe@kernel.dk>,
        Damien Le Moal <Damien.LeMoal@wdc.com>,
        "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>,
        Bart Van Assche <bvanassche@acm.org>,
        Mikulas Patocka <mpatocka@redhat.com>,
        "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [RFC PATCH v2 0/2] add simple copy support
Thread-Topic: [RFC PATCH v2 0/2] add simple copy support
Thread-Index: AQHWyi08xMuKL73ZZUaIarInYKlQvg==
Date:   Tue, 8 Dec 2020 13:24:40 +0000
Message-ID: <SN4PR0401MB3598226CD4A32F65320A47379BCD0@SN4PR0401MB3598.namprd04.prod.outlook.com>
References: <CGME20201204094719epcas5p23b3c41223897de3840f92ae3c229cda5@epcas5p2.samsung.com>
 <20201204094659.12732-1-selvakuma.s1@samsung.com>
 <20201207141123.GC31159@lst.de>
 <01fe46ac-16a5-d4db-f23d-07a03d3935f3@suse.de>
 <20201207192453.vc6clbdhz73hzs7l@mpHalley>
 <SN4PR0401MB35988951265391511EBC8C6E9BCD0@SN4PR0401MB3598.namprd04.prod.outlook.com>
 <20201208122248.utv7pqthmmn6uwv6@mpHalley>
 <SN4PR0401MB35983464199FB173FB0C29479BCD0@SN4PR0401MB3598.namprd04.prod.outlook.com>
 <20201208131333.xoxincxcnh7iz33z@mpHalley>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 10798663-c440-4025-bf1f-08d89b7c9e17
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2020 13:24:40.2752
 (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: TdRTaI6g/b3dVS9wANrGo3W7hTOb+JWw3Q4aOh4P33V5HBLvSx8iQjqjszszzV2ySMtCA/ZyEc4qJlvQIy9LCV13i3bMKVgmpTb/1WWbe+E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0401MB3597
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 08/12/2020 14:13, Javier Gonz=E1lez wrote:=0A=
> On 08.12.2020 12:37, Johannes Thumshirn wrote:=0A=
>> On 08/12/2020 13:22, Javier Gonz=E1lez wrote:=0A=
>>> Good idea. Are you thinking of a sysfs entry to select the backend?=0A=
>>=0A=
>> Not sure on this one, initially I thought of a sysfs file, but then=0A=
>> how would you do it. One "global" sysfs entry is probably a bad idea.=0A=
>> Having one per block device to select native vs emulation maybe? And=0A=
>> a good way to benchmark.=0A=
> =0A=
> I was thinking a per block device to target the use case where a certain=
=0A=
> implementation / workload is better one way or the other.=0A=
=0A=
Yes something along those lines.=0A=
=0A=
>>=0A=
>> The other idea would be a benchmark loop on boot like the raid library=
=0A=
>> does.=0A=
>>=0A=
>> Then on the other hand, there might be workloads that run faster with=0A=
>> the emulation and some that run faster with the hardware acceleration.=
=0A=
>>=0A=
>> I think these points are the reason the last attempts got stuck.=0A=
> =0A=
> Yes. I believe that any benchmark we run would be biased in a certain=0A=
> way. If we can move forward with a sysfs entry and default to legacy=0A=
> path, we would not alter current behavior and enable NVMe copy offload=0A=
> (for now) for those that want to use it. We can then build on top of it.=
=0A=
> =0A=
> Does this sound like a reasonable approach?=0A=
> =0A=
=0A=
Yes this sounds like a reasonable approach to me.=0A=