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: cb05Ci/hrHsxpOav2kRPMlk+bCYT449id9p7hrG8L8WAanK63M6QGtH20m73kxgRvVLyZX7jRf
 9/2uY2Huq/liyFoeetGxe9Ob3dcsm/bWJiK4l9N2hz5xVDWgOmmn8G4fy+s0piiMOerbDUSm1D
 Pdw6qkTSACd+Jms8UAi/N3zcQu5ig2hbmZ2w5TL2u3nLKZ1DcQATO/l9ARM2Z2yeVfApWJAadC
 Upcb4v5a7l7evIwSxVehT8njdpKCzb/9aA6DtvT1S4sz80SNlsH+E9wo/6ORJ0qoT4kWAPTxjf
 tfM=
From:   Damien Le Moal <Damien.LeMoal@wdc.com>
To:     Javier Gonzalez <javier@javigon.com>,
        Christoph Hellwig <hch@lst.de>
CC:     Kanchan Joshi <joshi.k@samsung.com>,
        "kbusch@kernel.org" <kbusch@kernel.org>,
        "axboe@kernel.dk" <axboe@kernel.dk>,
        "sagi@grimberg.me" <sagi@grimberg.me>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
        Nitesh Shetty <nj.shetty@samsung.com>,
        SelvaKumar S <selvakuma.s1@samsung.com>
Subject: Re: [PATCH 2/2] nvme: add emulation for zone-append
Thread-Topic: [PATCH 2/2] nvme: add emulation for zone-append
Thread-Index: AQHWdSEOep7b6SwjrkaV8sjqDWd2vg==
Date:   Wed, 19 Aug 2020 09:14:13 +0000
Message-ID: <CY4PR04MB3751DE6CEB9C233BF7C9D86AE75D0@CY4PR04MB3751.namprd04.prod.outlook.com>
References: <20200818052936.10995-1-joshi.k@samsung.com>
 <CGME20200818053256epcas5p46d0b66b3702192eb6617c8bba334c15f@epcas5p4.samsung.com>
 <20200818052936.10995-3-joshi.k@samsung.com> <20200818071249.GB2544@lst.de>
 <20200818095033.h6ybdwiq3ljagl5a@mpHalley.local>
 <20200818155004.GA26688@lst.de>
 <20200818180428.obipue6adpqqpwjj@MacBook-Pro.localdomain>
 <20200819074035.GA21991@lst.de>
 <20200819083353.rwblagiesocfcq7i@mpHalley.local>
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: 12a98498-06f7-4eeb-8c23-08d844203d75
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2020 09:14:13.1692
 (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: 0qX5cExk6aEzeIGNC/nyqz/c9IiiyvmtRUhJ7wquQOo2bV+VuD4UfzxtsUW9qxpOPTjySg7viE6zuNTN5b12gg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR04MB0249
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2020/08/19 17:34, Javier Gonzalez wrote:=0A=
> On 19.08.2020 09:40, Christoph Hellwig wrote:=0A=
>> On Tue, Aug 18, 2020 at 08:04:28PM +0200, Javier Gonzalez wrote:=0A=
>>> I understand that you want vendor alignment in the NVMe driver and I=0A=
>>> agree. We are not pushing for a non-append model - you can see that we=
=0A=
>>> are investing effort in implementing the append path in thee block laye=
r=0A=
>>> and io_uring and we will continue doing so as patches get merged.=0A=
>>>=0A=
>>> This said, we do have some OEM models that do not implement append and =
I=0A=
>>> would like them to be supported in Linux. As you know, new TPs are bein=
g=0A=
>>> standardized now and the append emulation is the based for adding=0A=
>>> support for this. I do not believe it is unreasonable to find a way to=
=0A=
>>> add support for this SSDs.=0A=
>>=0A=
>> I do not think we should support anything but Zone Append, especially no=
t=0A=
>> the new TP, which is going to add even more horrible code for absolutely=
=0A=
>> no good reason.=0A=
> =0A=
> I must admit that this is a bit frustrating. The new TP adds=0A=
> functionality beyond operating as an Append alternative that I would=0A=
> very much like to see upstream (do want to discuss details here).=0A=
> =0A=
> I understand the concerns about deviating from the Append model, but I=0A=
> believe we should find a way to add these new features. We are hiding=0A=
> all the logic in the NVMe driver and not touching the interface with the=
=0A=
> block layer, so the overall model is really not changed.=0A=
> =0A=
>>=0A=
>>> If you completely close the door this approach, the alternative is=0A=
>>> carrying off-tree patches to the several OEMs that use these devices.=
=0A=
>>> This is not good for the zoned ecosystem nor for the future of Zone=0A=
>>> Append.=0A=
>>=0A=
>> I really don't have a problem with that.  If these OEMs want to use=0A=
>> an inferior access model only, they have to pay the price for it.=0A=
>> I also don't think that proxy arguments are very useful.  If you OEMs=0A=
>> are troubled by carrying patches becomes they decided to buy inferior=0A=
>> drivers they are perfectly happy to argue their cause here on the list.=
=0A=
> =0A=
> I am not arguing as a proxy, I am stating the trouble we see from our=0A=
> perspective in having to diverge from mainline when our approach is=0A=
> being upstream first.=0A=
> =0A=
> Whether the I/O mode is inferior or superior, they can answer that=0A=
> themselves if they read this list.=0A=
>>=0A=
>>> Are you open to us doing some characterization and if the impact=0A=
>>> to the fast path is not significant, moving ahead to a Zone Append=0A=
>>> emulation like in SCSI? I will promise that we will remove this path if=
=0A=
>>> requests for these devices terminate.=0A=
>>=0A=
>> As said I do not think implementing zone append emulation or the TP that=
=0A=
>> shall not be named are a good idea for Linux.=0A=
> =0A=
> I would ask you to reconsider this position. I have a hard time=0A=
> understanding how zone append emulation is a good idea in SCSI and not=0A=
> in NVMe, when there is no performance penalty.=0A=
=0A=
While defining a zone append command for SCSI/ZBC is possible (using sense =
data=0A=
for returning the written offset), there is no way to define zone append fo=
r=0A=
SATA/ZAC without entirely breaking the ATA command model. This is why we we=
nt=0A=
after an emulation implementation instead of trying to standardized native=
=0A=
commands. That implementation does not have any performance impact over reg=
ular=0A=
writes *and* zone write locking does not in general degrade HDD write=0A=
performance (only a few corner cases suffer from it). Comparing things equa=
lly,=0A=
the same could be said of NVMe drives that do not have zone append native=
=0A=
support: performance will be essentially the same using regular writes and=
=0A=
emulated zone append. But mq-deadline and zone write locking will significa=
ntly=0A=
lower performance for emulated zone append compared to a native zone append=
=0A=
support by the drive.=0A=
=0A=
=0A=
-- =0A=
Damien Le Moal=0A=
Western Digital Research=0A=