Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2964519pxa; Tue, 18 Aug 2020 02:52:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCpk0PRGiqwMst1fBWYjSVONNBGLWJ3MTC17DV1Lix6rletow5YVW97gMfc6s1g885FTkB X-Received: by 2002:a17:906:600f:: with SMTP id o15mr18772927ejj.529.1597744341222; Tue, 18 Aug 2020 02:52:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597744341; cv=none; d=google.com; s=arc-20160816; b=I7uvNU0Cp639Y5HYQeMYYzpihR1vYtqo26H3S9rRZgvYiYzya6ARvOK+ST8yEvX34e BI1xwkjjk5yhmseskAQjbrnESlZSGHSMRRwCB7fjPI/bNdZyYzZTGQCLfng24CrqFY1s us3LWfhHz4lHTDjdEo7hxuWIzGC9H81BvYXXf9MZXwoK4xEvckS5wEIC1tc/tBqjngGd x0IDsuOaonDGBCU2vp1gI3118mz7lD19dl9kDJD3Q05NXlMfDYW9lrfi9bZQZ9VUkmPd kmzOYJyDSBcMQqEwzaaypqW1Ty+mZTfR2azSSVa4oyuIucYfcsFBi01myUMmVtokadeC 4jVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:date:from :dkim-signature; bh=i5vDKEZg30AIs6a0nWYqfPKaiEsU3ewP/cuwaplcd5Y=; b=lJDxyaO8nMLkQ5icir0SlrZe4Es5x0C5maiogZTVBHH5TDoxf/3P3D+BhSd+aQ0OeQ e60BS30nmOoxgAWX9zZwfq++3JCG5RIN+lsHBJm3+pNYH8SVhBvadvNVa17+CC9OzX9o nCXIkG1/gGp57Xm9JuPJnRkxkNNorZp8VN3r2vJr9LIcbaz4XbpNlYjvxRXhNF4Fek6K oEmZaB1Q3coqMSIA9Bi49b91crZrw0I0vnPBVyifmYaNbdb7CRrdjXHFOkxFp2m0IJyS oWHNv7ZykcADrBxRHJcXHRYKmyeETjkmqOqkL+B3JPGkQIC0FkJQ94KS/fLd8SQ/dO/G xCeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@javigon-com.20150623.gappssmtp.com header.s=20150623 header.b=1dqfVxQF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a5si12730078edu.87.2020.08.18.02.51.57; Tue, 18 Aug 2020 02:52:21 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@javigon-com.20150623.gappssmtp.com header.s=20150623 header.b=1dqfVxQF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726638AbgHRJuj (ORCPT + 99 others); Tue, 18 Aug 2020 05:50:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726398AbgHRJuh (ORCPT ); Tue, 18 Aug 2020 05:50:37 -0400 Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 061C4C061389 for ; Tue, 18 Aug 2020 02:50:37 -0700 (PDT) Received: by mail-wm1-x341.google.com with SMTP id k8so16376357wma.2 for ; Tue, 18 Aug 2020 02:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=javigon-com.20150623.gappssmtp.com; s=20150623; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=i5vDKEZg30AIs6a0nWYqfPKaiEsU3ewP/cuwaplcd5Y=; b=1dqfVxQFClI+zfejIh1qTvSsngHFLaKqPtzKLGLjelw3bC2aQD6QKBit3dijblXqri 4qIVwFR71xk25st/eAJvzncev4uETStFXHoVK9U48yYtee49fWBR/bl4kYMNejbhNhQ4 epGdb7Ih3XcfLxQKGu5WwJK6MitmuZtqC+aF/TbPUuLbq9//Flfs148+xhXZ0ONP6UdI 4e2WW1d28D7iKP6tqaCTR+bku4ZUdrbOt9+wFwU02wM4f7QcWnU3mPSBsCB2qKR1kcaB La+Em2GybOQoR5kWGO4FflyNc/VDvPuM98HdRfBPIOBwY+JA4XqOzOIsUmI0/G9wMLzs kMww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=i5vDKEZg30AIs6a0nWYqfPKaiEsU3ewP/cuwaplcd5Y=; b=Tat7i6ZlbWmkIZyvgjSOr2w1vMqJldfSEAmMPlKGP46xeH6UhIpbcxskrHaf6/W/9B x8FRjgyj/T5vLEqcDkORcJexmehduLrniRUzIhSOKyuMp0/TCUoyde0tUMFmo/zylELm 4SXP4P97ktieKifAD9qTLcDqk90JqbhFPw1zf+hM9e8vSMl1LJrgBWqAZ8I3NtFx+Uy5 pp4FHsa3RuaeYA+g4/NFEdPPJrxUvjcTWkrIGMZVi4hPOnOufwjQx4V35fdSl9CuN165 4Yw74cxGc1THvqutH7OpHwmLTucH7zSGIQ8CzydHlAMUDAjpIZayu1wt9aYVeyB7mEUR ITtw== X-Gm-Message-State: AOAM5335VCSIiXMcjxA8GrWzvchQqoUk0pK50pZA9xS3e1kv3FXHl2bx X2CcSIyb5dN7kN8Q9Of9l7PVgw== X-Received: by 2002:a1c:4c17:: with SMTP id z23mr19576673wmf.49.1597744235584; Tue, 18 Aug 2020 02:50:35 -0700 (PDT) Received: from localhost ([194.62.217.57]) by smtp.gmail.com with ESMTPSA id p3sm31479709wma.44.2020.08.18.02.50.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2020 02:50:34 -0700 (PDT) From: Javier Gonzalez X-Google-Original-From: Javier Gonzalez Date: Tue, 18 Aug 2020 11:50:33 +0200 To: Christoph Hellwig Cc: Kanchan Joshi , kbusch@kernel.org, Damien.LeMoal@wdc.com, axboe@kernel.dk, sagi@grimberg.me, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, johannes.thumshirn@wdc.com, Nitesh Shetty , SelvaKumar S Subject: Re: [PATCH 2/2] nvme: add emulation for zone-append Message-ID: <20200818095033.h6ybdwiq3ljagl5a@mpHalley.local> References: <20200818052936.10995-1-joshi.k@samsung.com> <20200818052936.10995-3-joshi.k@samsung.com> <20200818071249.GB2544@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline In-Reply-To: <20200818071249.GB2544@lst.de> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18.08.2020 09:12, Christoph Hellwig wrote: >On Tue, Aug 18, 2020 at 10:59:36AM +0530, Kanchan Joshi wrote: >> If drive does not support zone-append natively, enable emulation using >> regular write. >> Make emulated zone-append cmd write-lock the zone, preventing >> concurrent append/write on the same zone. > >I really don't think we should add this. ZNS and the Linux support >were all designed with Zone Append in mind, and then your company did >the nastiest possible move violating the normal NVMe procedures to make >it optional. But that doesn't change the fact the Linux should keep >requiring it, especially with the amount of code added here and how it >hooks in the fast path. I understand that the NVMe process was agitated and that the current ZNS implementation in Linux relies in append support from the device perspective. However, the current TP does allow for not implementing append, and a number of customers are requiring the use of normal writes, which we want to support. During the initial patch review we discussed this and we agreed that the block layer is designed for append on zone devices, and that for the foreseeable future this was not going to change. We therefore took the feedback and followed a similar approach as in the SCSI driver for implementing append emulation. We are happy to do more characterization on the impact of these hooks in the non-zoned hast path and eventually changing the approach if this proves to be a problem. Our thought is to isolate any potential performance degradation to the zoned path using the emulation (we do not see any ATM). Do you have any early suggestion on how you this patch should look like to be upstreamable? Javier