From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F598C43441 for ; Fri, 16 Nov 2018 10:17:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 550B32089D for ; Fri, 16 Nov 2018 10:17:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 550B32089D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-block-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727534AbeKPU3f (ORCPT ); Fri, 16 Nov 2018 15:29:35 -0500 Received: from verein.lst.de ([213.95.11.211]:48611 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727454AbeKPU3f (ORCPT ); Fri, 16 Nov 2018 15:29:35 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id F3A1668D60; Fri, 16 Nov 2018 11:17:52 +0100 (CET) Date: Fri, 16 Nov 2018 11:17:52 +0100 From: Christoph Hellwig To: Hannes Reinecke Cc: Christoph Hellwig , Mike Snitzer , linux-nvme@lists.infradead.org, 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: [PATCH] nvme: allow ANA support to be independent of native multipathing Message-ID: <20181116101752.GA21531@lst.de> References: <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> <37098edd-4dea-b58f-bca6-3be9af8ec4ee@suse.de> <20181116094947.GA19296@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Fri, Nov 16, 2018 at 11:06:32AM +0100, Hannes Reinecke wrote: > Ok, so would you be happy with making ANA support configurable? I've looked a bit over the whole situation, and what I think we need to do is: a) warn if we see a ANA capable device without multipath support so people know it is not going to work properly. b) deprecate the multipath module option. It was only intended as a migration for any pre-existing PCIe multipath user if there were any, not to support any new functionality. So for 4.20 put in a patch that prints a clear warning when it is used, including a link to the nvme list, and then for 4.25 or so remove it entirely unless something unexpected come up. This whole drama of optional multipath use has wasted way too much of everyones time already. From mboxrd@z Thu Jan 1 00:00:00 1970 From: hch@lst.de (Christoph Hellwig) Date: Fri, 16 Nov 2018 11:17:52 +0100 Subject: [PATCH] nvme: allow ANA support to be independent of native multipathing In-Reply-To: References: <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> <37098edd-4dea-b58f-bca6-3be9af8ec4ee@suse.de> <20181116094947.GA19296@lst.de> Message-ID: <20181116101752.GA21531@lst.de> On Fri, Nov 16, 2018@11:06:32AM +0100, Hannes Reinecke wrote: > Ok, so would you be happy with making ANA support configurable? I've looked a bit over the whole situation, and what I think we need to do is: a) warn if we see a ANA capable device without multipath support so people know it is not going to work properly. b) deprecate the multipath module option. It was only intended as a migration for any pre-existing PCIe multipath user if there were any, not to support any new functionality. So for 4.20 put in a patch that prints a clear warning when it is used, including a link to the nvme list, and then for 4.25 or so remove it entirely unless something unexpected come up. This whole drama of optional multipath use has wasted way too much of everyones time already.