Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2332065ybe; Tue, 3 Sep 2019 11:15:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqySOSyI1ojmT/y5aE8Kf15PCIlz6gkEcSsRyZLBReWb5XqZyKoYdw/J+tk6PyY2rSXu/qPo X-Received: by 2002:aa7:9a84:: with SMTP id w4mr14727356pfi.244.1567534527782; Tue, 03 Sep 2019 11:15:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567534527; cv=none; d=google.com; s=arc-20160816; b=an2OYIgk3EVFNweFHfGCng3YkBUpXIXBTvsdq3qWr8O5n3IYC1qT0B//Fr2Nm4P4Ie 7+S/705dFRnQIpp3hwsfjxqlbRIe9LjYBiHYuMNsdCcu12+lc/5XI9vCi9NqInzjliV1 wxXKYSRxmTHtuBnFzZWWFYEAY790oDJOeC3pr6bqL5eBP+6R5qugxbu4/UkjQxggfmMS jFSDHPG2EAUES0toIKJHDZ4FenTKE0GkxCCKFZfq50IYIFy/aTyk7mDAAGuNfbn8quek Coe/pA9fuOAcOHYKUHYUrnuPL7Gc/LVzc+nwaomsWjsob2E9YPG8c4SXljLh1Ce9JmRH V22g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to; bh=30G7ABoHic0Xc1hE/1Y6y/sq02D0OYN42zAvQ3vCQpE=; b=ZHVpr7tqZ2FswHembYXMUID7+iZFhp53E7h/oTe/12ehpEYSHVj8sjqPWapXClHqQ0 INJbYIRZneks3yCqbctiTYRYdQ94RchXBcp+6RdLmapp5eqG3DnmW3JM3wslAVeFmCKU jW1mI9+1LG/qI3SU+BnYF6VJo4ugFaU3jf+cTHpjObtZjddJk3E/D4jJ06rPqOJHUiQy 6+RpCaGRqgHy+s+GTTdaD6wSehn2yP9OpFN8rGISYsoLy7t1pdJC22U2LWR2pQqnhAG5 70O+lgNt4nlzIxxLIXH2cr60Z0U9+1A6izeQEdL1gf0O65t40tDvk+DoDUrhBjBKJdCt xorg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 143si14807894pgc.479.2019.09.03.11.15.12; Tue, 03 Sep 2019 11:15:27 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730253AbfICSNu (ORCPT + 99 others); Tue, 3 Sep 2019 14:13:50 -0400 Received: from ale.deltatee.com ([207.54.116.67]:35214 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727069AbfICSNu (ORCPT ); Tue, 3 Sep 2019 14:13:50 -0400 Received: from guinness.priv.deltatee.com ([172.16.1.162]) by ale.deltatee.com with esmtp (Exim 4.89) (envelope-from ) id 1i5DJ1-0005Zx-O9; Tue, 03 Sep 2019 12:13:28 -0600 To: Keith Busch Cc: Keith Busch , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, Christoph Hellwig , Sagi Grimberg , Jens Axboe , Hannes Reinecke , "Martin K . Petersen" References: <20190831000139.7662-1-logang@deltatee.com> <20190831152910.GA29439@localhost.localdomain> <33af4d94-9f6d-9baa-01fa-0f75ccee263e@deltatee.com> <20190903164620.GA20847@localhost.localdomain> From: Logan Gunthorpe Message-ID: Date: Tue, 3 Sep 2019 12:13:24 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190903164620.GA20847@localhost.localdomain> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.162 X-SA-Exim-Rcpt-To: martin.petersen@oracle.com, hare@suse.com, axboe@fb.com, sagi@grimberg.me, hch@lst.de, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, keith.busch@intel.com, kbusch@kernel.org X-SA-Exim-Mail-From: logang@deltatee.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on ale.deltatee.com X-Spam-Level: X-Spam-Status: No, score=-8.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, GREYLIST_ISWHITE autolearn=ham autolearn_force=no version=3.4.2 Subject: Re: [PATCH] nvme-core: Fix subsystem instance mismatches X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-09-03 10:46 a.m., Keith Busch wrote: > On Tue, Sep 03, 2019 at 10:08:01AM -0600, Logan Gunthorpe wrote: >> On 2019-08-31 9:29 a.m., Keith Busch wrote: >>> On Fri, Aug 30, 2019 at 06:01:39PM -0600, Logan Gunthorpe wrote: >>>> To fix this, assign the subsystem's instance based on the instance >>>> number of the controller's instance that first created it. There should >>>> always be fewer subsystems than controllers so the should not be a need >>>> to create extra subsystems that overlap existing controllers. >>> >>> The subsystem's lifetime is not tied to the controller's. When the >>> controller is removed and releases its instance, the next controller >>> to take that available instance will create naming collisions with the >>> subsystem still using it. >>> >> >> Hmm, yes, ok. >> >> So perhaps we can just make the subsystem prefer the ctrl's instance >> when allocating the ID? Then at least, in the common case, the >> controller numbers will match the subsystem numbers. Only when there's >> random hot-plugs would the numbers get out of sync. > > I really don't know about a patch that works only on static > configurations. Connects and disconnects do happen on live systems, > so the numerals will inevitably get out of sync. Well this depends on how big a problem we think the number mismatch is. Right now it's pretty annoying because numbers aren't matching for non-CMIC controllers in simple setups on boot. I think having a small patch that makes it more consistent for the static would be worth it and if CMIC controllers with significant hot-plug events have mismatches that seems more understandable to me. > Could we possibly make /dev/nvmeX be a subsystem handle without causing > trouble for anyone? This would essentially be the same thing as today > for non-CMIC controllers with a device-per-controller and only affects > the CMIC ones. Well then we'd have to be able to do everything that's possible with a controller via the subsystem and it would have to multiplex all admin commands for CMIC ones, etc to a sensible controller. This might make sense in the long term but it sounds like a larger project than I have time to take on. Logan