Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp522140imu; Fri, 16 Nov 2018 06:14:42 -0800 (PST) X-Google-Smtp-Source: AJdET5f/9oHphvOqUix03hBb6GsaY1iM6LwSoztCmUMJ0LudhRS5I97Q+G7TtiTfXB7Nzh6WZIp3 X-Received: by 2002:a63:2315:: with SMTP id j21mr10146544pgj.297.1542377682551; Fri, 16 Nov 2018 06:14:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542377682; cv=none; d=google.com; s=arc-20160816; b=XHi/pFhD2NH0Wk81APlHqM9QiIMKzvg1weWOZXWByP1vsH9wfTUvascpc1X1vMT3Pz Fp2tuLAfdaa0fYg50GcyQgvfj/r5qxz+pqFbayVMTvGfl9Jqr/2J7E5UC4ofbbazKB38 N4wPv0xWsvLNGrsFBXKmnOBuqqHOWcjubKhYLihLYbUbnESHkR8zSVdBF/d8jKf2Q8S0 AI4QrYYRy5741v55nhQBTIWVXokQvtv6BKgxW8U2xB81gV06bFGEpeCEfJB5Q1Qwp7Af 59Aj9qcHofxJQTjWFmq24FcexgM+TckZG1F+acmpk4wnyAZB9WbaIfQRiIS/iAEacLeg snog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=akqSw98abxF6aZULS4LjTaA7xhabWgIxhgL6bqO4mFM=; b=vLzgdNeweMSQOkUh6TRJJMRYI6nhGxqSG7sbWKHPxiUAG5Q7eJXU25HwX1wU/7eqWm mtebQb2QXql8iRgpXf6P+Tbc3e+rCV884Hv3/wCklch62cMprKgeNyzHzu1QDg4LZvrV f8TrnyEyOeS4xiISdHfh13QmWKRYeuZpXGfO/dOZ8knanxCWz3WGNYvVoyxr5HC/ngz1 zaQTeXNSzeC4tH2VzCU9t/AhyIsFIes6QsZW+6/dw00EZDhuGXSbIqbszJNRCvNTknWk ENRvAx1OkDm94um5xQzAsG1fBqMt2Bnjx7vucKDD1WwAjdeT11FpWJ+wx/dr2GSb9Ut9 cTFw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c17si25138136pgl.385.2018.11.16.06.14.27; Fri, 16 Nov 2018 06:14:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389696AbeKQAZI (ORCPT + 99 others); Fri, 16 Nov 2018 19:25:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39284 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728079AbeKQAZI (ORCPT ); Fri, 16 Nov 2018 19:25:08 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4E3ED169739; Fri, 16 Nov 2018 14:12:34 +0000 (UTC) Received: from localhost (unknown [10.18.25.149]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AD075611C3; Fri, 16 Nov 2018 14:12:30 +0000 (UTC) Date: Fri, 16 Nov 2018 09:12:29 -0500 From: Mike Snitzer To: Christoph Hellwig Cc: linux-nvme@lists.infradead.org, Hannes Reinecke , Keith Busch , Sagi Grimberg , axboe@kernel.dk, Martin Wilck , lijie , xose.vazquez@gmail.com, chengjike.cheng@huawei.com, shenhong09@huawei.com, dm-devel@redhat.com, wangzhoumengjian@huawei.com, christophe.varoqui@opensvc.com, bmarzins@redhat.com, sschremm@netapp.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: nvme: allow ANA support to be independent of native multipathing Message-ID: <20181116141229.GC28870@redhat.com> References: <2691abf6733f791fb16b86d96446440e4aaff99f.camel@suse.com> <20181112215323.GA7983@redhat.com> <20181113161838.GC9827@localhost.localdomain> <20181113180008.GA12513@redhat.com> <20181114053837.GA15086@redhat.com> <30cf7af7-8826-55bd-e39a-4f81ed032f6d@suse.de> <20181114174746.GA18526@redhat.com> <87c931e5-4ac9-1795-8d40-cc5541d3ebcf@suse.de> <20181115174605.GA19782@redhat.com> <20181116091458.GA17267@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181116091458.GA17267@lst.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 16 Nov 2018 14:12:34 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 16 2018 at 4:14am -0500, Christoph Hellwig wrote: > On Thu, Nov 15, 2018 at 12:46:05PM -0500, Mike Snitzer wrote: > > Whether or not ANA is present is a choice of the target implementation; > > the host (and whether it supports multipathing) has _zero_ influence on > > this. If the target declares a path as 'inaccessible' the path _is_ > > inaccessible to the host. As such, ANA support should be functional > > even if native multipathing is not. > > > > Introduce ability to always re-read ANA log page as required due to ANA > > error and make current ANA state available via sysfs -- even if native > > multipathing is disabled on the host (e.g. nvme_core.multipath=N). > > The first part I could see, but I still want to make it conditional > in some way as nvme is going into deeply embedded setups, and I don't > want to carry the weight of the ANA code around for everyone. So disabling CONFIG_NVME_MULTIPATH isn't adequate? You see a need for enabling CONFIG_NVME_MULTIPATH but disallowing consideration of ANA state management for these embedded cases? That doesn't make much sense in that ANA won't be enabled on the target, and if it is then shouldn't the NVMe host enable ANA support? > The second I fundamentally disagree with. And even if you found agreement > it would have to be in a separate patch as it is a separate feature. In a later mail you clarified that by "second" you meant the sysfs export. nvme_ns_id_attrs_are_visible() calls nvme_ctrl_use_ana() to know whether to export the ana state via sysfs. Makes no sense to enable ANA to work, independent of native multipathing, and then even though ANA is active disallow exporting the associated ANA state. We need consistency.. if the sysfs file exists it means ANA state is being managed. All I can figure is that what you're suggesting is born out of disallowing uses you fundamentally disagree with (e.g. multipath-tools reading the ANA state from this sysfs file). Mike