From: Keith Busch <kbusch@kernel.org>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: Jens Axboe <axboe@fb.com>, Hannes Reinecke <hare@suse.com>,
Sagi Grimberg <sagi@grimberg.me>,
"Martin K . Petersen" <martin.petersen@oracle.com>,
linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
Keith Busch <keith.busch@intel.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH] nvme-core: Fix subsystem instance mismatches
Date: Tue, 3 Sep 2019 10:46:20 -0600 [thread overview]
Message-ID: <20190903164620.GA20847@localhost.localdomain> (raw)
In-Reply-To: <33af4d94-9f6d-9baa-01fa-0f75ccee263e@deltatee.com>
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.
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.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
WARNING: multiple messages have this Message-ID (diff)
From: Keith Busch <kbusch@kernel.org>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: Keith Busch <keith.busch@intel.com>,
linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
Jens Axboe <axboe@fb.com>, Hannes Reinecke <hare@suse.com>,
"Martin K . Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH] nvme-core: Fix subsystem instance mismatches
Date: Tue, 3 Sep 2019 10:46:20 -0600 [thread overview]
Message-ID: <20190903164620.GA20847@localhost.localdomain> (raw)
In-Reply-To: <33af4d94-9f6d-9baa-01fa-0f75ccee263e@deltatee.com>
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.
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.
next prev parent reply other threads:[~2019-09-03 16:48 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-31 0:01 [PATCH] nvme-core: Fix subsystem instance mismatches Logan Gunthorpe
2019-08-31 0:01 ` Logan Gunthorpe
2019-08-31 15:29 ` Keith Busch
2019-08-31 15:29 ` Keith Busch
2019-09-03 16:08 ` Logan Gunthorpe
2019-09-03 16:08 ` Logan Gunthorpe
2019-09-03 16:46 ` Keith Busch [this message]
2019-09-03 16:46 ` Keith Busch
2019-09-03 18:13 ` Logan Gunthorpe
2019-09-03 18:13 ` Logan Gunthorpe
2019-09-04 6:05 ` Christoph Hellwig
2019-09-04 6:05 ` Christoph Hellwig
2019-09-04 14:44 ` Keith Busch
2019-09-04 14:44 ` Keith Busch
2019-09-04 15:42 ` Christoph Hellwig
2019-09-04 15:42 ` Christoph Hellwig
2019-09-04 15:54 ` Keith Busch
2019-09-04 15:54 ` Keith Busch
2019-09-04 16:02 ` Christoph Hellwig
2019-09-04 16:02 ` Christoph Hellwig
2019-09-04 16:07 ` Logan Gunthorpe
2019-09-04 16:07 ` Logan Gunthorpe
2019-09-04 16:35 ` Keith Busch
2019-09-04 16:35 ` Keith Busch
2019-09-04 17:01 ` Logan Gunthorpe
2019-09-04 17:01 ` Logan Gunthorpe
2019-09-04 17:14 ` Keith Busch
2019-09-04 17:14 ` Keith Busch
2019-09-04 17:29 ` Logan Gunthorpe
2019-09-04 17:29 ` Logan Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190903164620.GA20847@localhost.localdomain \
--to=kbusch@kernel.org \
--cc=axboe@fb.com \
--cc=hare@suse.com \
--cc=hch@lst.de \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=logang@deltatee.com \
--cc=martin.petersen@oracle.com \
--cc=sagi@grimberg.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.