Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp703551pxa; Wed, 19 Aug 2020 12:29:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwLk9fNp1wryWOBVfoEySfpRPmviGkBouOBqAekh87XiqfpJGwJqcNEjlpBJlfbQqu8KYw/ X-Received: by 2002:a17:906:401b:: with SMTP id v27mr26296429ejj.300.1597865340393; Wed, 19 Aug 2020 12:29:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597865340; cv=none; d=google.com; s=arc-20160816; b=D46X0goPXHjYWol8CRa76n6UrKek5iquuPTyC+fWdt+gxu5ymcAToUFIEiF8vEoCzl ewnm9vhyllLUcchq0Ly+ulSwLINa//WtQ5ZYS8KZdqJTcmT3oYavZJd+XGxI1xF6KqaO /C47akatCHgfALqGZv0ivpwBS86dKFu5doU8HGClu4Enbvo8AC71OZbDTcwdTM3beI/3 ue0lTBBK4ZQnyNnXJ2/7nDCLmWqrqd/MbdJbaKnF1MR1ifasMPrULfxeu8QoOk90RorM +WrUwDS5E07yBSYMlWxhW5Qm3WvJnYBrSFvWrB69siMWhh8euUY5+ePDOgjQqfrE3VSl IhQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=uIHy/4+dOTIzbxPNc7n6E/xZy0w8cFL8jWiQ0sl5YxQ=; b=bjA7EIJ+VcA5kHpo3y+dVvThtVXkLVdnc4obkG83sAxLgkldfOpMi1PXe9Wah5qUrq Do56zpP9g15wEbxXZ9Im7nHwI9PckrWl4zv7OeN4lP/+uSMfp5R2BwM1jrltBwQe9Lly sqUuM98f5iLE+op+pYPfo8lxSiYoOEhQGWu0YvajO4q2cv+mtoT+pZveOhVJawWunCp7 RFclPM4NK7pwfmx9ICjZKQJDO1V5QdzoCn4QvurtKnG9jOg4CVulkcMNW27syVts76W1 LEfiMYRlzStryGT65WikDY+m1fDqfnpqLwPS5kXFxfOhotSIxgsUxyfjr1Nu9WOooTEU aSMQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=nR7G5SwF; 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 t2si16661130eji.602.2020.08.19.12.28.34; Wed, 19 Aug 2020 12:29:00 -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=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=nR7G5SwF; 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 S1726617AbgHSTZz (ORCPT + 99 others); Wed, 19 Aug 2020 15:25:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39912 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726435AbgHSTZy (ORCPT ); Wed, 19 Aug 2020 15:25:54 -0400 Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1032EC061757 for ; Wed, 19 Aug 2020 12:25:54 -0700 (PDT) Received: by mail-pj1-x1044.google.com with SMTP id kr4so1558069pjb.2 for ; Wed, 19 Aug 2020 12:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uIHy/4+dOTIzbxPNc7n6E/xZy0w8cFL8jWiQ0sl5YxQ=; b=nR7G5SwFp2JNr6fuvAhbEb1o7xKTXFbeB+0VOd0exvnNhw75pIp+ZO987UkhaH7KCl kt1OPnfzX8XXOQntKZrAGq3pqfKbPDeKB4RyDO/DBvTuEIq3gwsuXc9J1yqb82gXjhr4 jPaPFV/gvbpptAaLLv3YEznM/o1wZjgGklS6dY52+sTfbOS9zYUi2owz1OQqd7f9Vn/v B2DwrK73+KEfTU3mWrj68bpX71UhgsCbVXK1aFFeFTHJ0kOMzZVHeG1bYX25Pgfy9LPe 5D5UmMGCQp9rJ2Txbw97Nz+dmPiqGWjC7//2sslnuoM5Jwz8xmO9fDin91pG11CTB6Ge KXLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uIHy/4+dOTIzbxPNc7n6E/xZy0w8cFL8jWiQ0sl5YxQ=; b=Q0++qxXCyX/duTZmiCCYRbWVg+ipe7rF4jPZ/gw5osN/EvnsLKs+An83X5uqeMafWY A2wtBRduGp4WziU554mZo8dRdg521Y+k+7yjeSxQfZxyMLd7SsfIoyvx8Hvqv2Son9KK 7GjY+u5YRTgHHFGs9xA29/WAAFc5GYqFthrc9t2nEWHsY3uy1PqUh3c3RdrzqgB3pZZM AqMbcI42YkgDIp4lK893V3Ii+4KGuY2QJJRXnVxeXyQyeZfCrY1oOSzJfIdaqTf/bxXq L7YGdzRqY0+saJErZZtsoRNc/ZG2Au9YXU7O3Vo/yRzRbCm/zWQf7NR/+7MFsX2Dqnep Y21Q== X-Gm-Message-State: AOAM533NHI79RLHlQ5h9fEobWsJW0RUA9jjpr9N8V5EJL80jxgyZr4w3 F2XT4oFhnuxq0FkLkZx17ioXDw== X-Received: by 2002:a17:902:7245:: with SMTP id c5mr1136646pll.317.1597865153509; Wed, 19 Aug 2020 12:25:53 -0700 (PDT) Received: from [192.168.1.182] ([66.219.217.173]) by smtp.gmail.com with ESMTPSA id s185sm26735618pgc.18.2020.08.19.12.25.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Aug 2020 12:25:52 -0700 (PDT) Subject: Re: [PATCH 2/2] nvme: add emulation for zone-append To: david.fugate@linux.intel.com, Christoph Hellwig , Kanchan Joshi Cc: "kbusch@kernel.org" , "Damien.LeMoal@wdc.com" , "sagi@grimberg.me" , "linux-nvme@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "johannes.thumshirn@wdc.com" , Nitesh Shetty , SelvaKumar S , Javier Gonzalez References: <20200818052936.10995-1-joshi.k@samsung.com> <20200818052936.10995-3-joshi.k@samsung.com> <20200818071249.GB2544@lst.de> From: Jens Axboe Message-ID: <9fa64efe-8477-5d33-20ed-9619a9fe8d70@kernel.dk> Date: Wed, 19 Aug 2020 13:25:50 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/19/20 12:11 PM, David Fugate wrote: > On Tue, 2020-08-18 at 07:12 +0000, 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. > > Intel does not support making *optional* NVMe spec features *required* > by the NVMe driver. It's not required, the driver will function quite fine without it. If you want to use ZNS it's required. The Linux driver thankfully doesn't need any vendor to sign off on what it can or cannot do, or what features are acceptable. > It's forgivable WDC's accepted contribution didn't work with other > vendors' devices choosing not to implement the optional Zone Append, > but it's not OK to reject contributions remedying this. Provided > there's no glaring technical issues, Samsung's contribution should be > accepted to maintain both spec compliance as well as vendor neutrality. It's *always* ok to reject contributions, if those contributions cause maintainability issues, unacceptable slowdowns, or whatever other issue that the maintainers of said driver don't want to deal with. Any contribution should be judged on merit, not based on political decisions or opinions. Obviously this thread reeks of it. -- Jens Axboe