linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: hch@lst.de (Christoph Hellwig)
Subject: [PATCH 06/18] nvme: split a new struct nvme_ctrl out of struct nvme_dev
Date: Thu, 22 Oct 2015 09:37:14 +0200	[thread overview]
Message-ID: <20151022073714.GB20076@lst.de> (raw)
In-Reply-To: <1445462626.3307.64.camel@linux.intel.com>

On Wed, Oct 21, 2015@02:23:46PM -0700, J Freyensee wrote:
> > -struct nvme_dev {
> > -	struct list_head node;
> > -	struct nvme_queue **queues;
> > +struct nvme_ctrl {
> 
> Whether it is a PCIe NVMe device with multiple controllers or something
> beyond PCIe, I think an instance of struct nvme_ctrl is going to need
> to know its cntlid.  How does this struct know its cntlid?  I'm not
> initially seeing it.  I think it would make more sense to have struct
> nvme_ctrl have a member that stores its cntlid value.  It would
> basically be the "name" of the specific nvme_ctrl instance allocated.

Right now nothing in the Linux PCIe driver knows the cntlid.  At least
for PCIe it's also fairly uninteresting for the driver.  Remeber this
is just a simple split for now, additional functionality will be built
on top of it.

> > -	bool subsystem;
> 
> Also, this is something probably a bit more far visioned, but I think
> struct nvme_ctrl would need a mechanism to know what NVMe subsystem it
> sits in.  Even if 'subsystem' stayed in the struct, I'm not sure how a
> bool would work for this.

See the reply for Keith on what this field does.  But at least for PCIe
the containing subsystem isn't all that interesting for the driver.  Maybe
as an additional safety check for the Namespae GUIDs in a multipathing
setup, but that's about it.

> > @@ -78,7 +48,7 @@ struct nvme_dev {
> >  struct nvme_ns {
> >  	struct list_head list;
> >  
> > -	struct nvme_dev *dev;
> > +	struct nvme_ctrl *ctrl;
> 
> This seems a bit backwards to me.  It's the controller (cntlid) that is
> going to tell the host how many namespaces are associated with it via
> the NVMe Identify commands.  Thus, I would have thought that a list of
> struct nvme_ns instances would be in a struct nvme_ctrl definition, not
> vice-versa.  Unless '*ctrl' is going to be used as a back pointer?  But
> then in 'struct nvme_ctrl' I didn't see initially see anything that
> associates itself to the namespaces attached to it.

The namespace lists moves to nvme_ctrl in this list, and the dev field
has always been a backpointer that's now replaced with a backpointer to
the nvme_ctrl structure.

  parent reply	other threads:[~2015-10-22  7:37 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-16  5:58 nvme driver split V2 Christoph Hellwig
2015-10-16  5:58 ` [PATCH 01/18] nvme: add missing unmaps in nvme_queue_rq Christoph Hellwig
2015-10-20 10:04   ` Sagi Grimberg
2015-10-20 14:07     ` Busch, Keith
2015-10-16  5:58 ` [PATCH 02/18] nvme: move struct nvme_iod to pci.c Christoph Hellwig
2015-10-20 10:04   ` Sagi Grimberg
2015-10-16  5:58 ` [PATCH 03/18] nvme: split command submission helpers out of pci.c Christoph Hellwig
2015-10-20 10:07   ` Sagi Grimberg
2015-10-21 18:48   ` J Freyensee
2015-10-16  5:58 ` [PATCH 04/18] nvme: add a vendor field to struct nvme_dev Christoph Hellwig
2015-10-20 10:08   ` Sagi Grimberg
2015-10-21 18:58   ` J Freyensee
2015-10-21 19:10     ` Busch, Keith
2015-10-16  5:58 ` [PATCH 05/18] nvme: use offset instead of a struct for registers Christoph Hellwig
2015-10-16 17:30   ` Busch, Keith
2015-10-21 20:28   ` J Freyensee
2015-10-16  5:58 ` [PATCH 06/18] nvme: split a new struct nvme_ctrl out of struct nvme_dev Christoph Hellwig
2015-10-20 10:19   ` Sagi Grimberg
2015-10-20 10:26     ` Christoph Hellwig
2015-10-20 10:44       ` Sagi Grimberg
2015-10-20 11:30         ` Christoph Hellwig
2015-10-21 14:40           ` Sagi Grimberg
2015-10-21 21:23   ` J Freyensee
2015-10-21 22:51     ` Busch, Keith
2015-10-22  0:15       ` J Freyensee
2015-10-22  7:37     ` Christoph Hellwig [this message]
2015-10-16  5:58 ` [PATCH 07/18] nvme: simplify nvme_setup_prps calling convention Christoph Hellwig
2015-10-20 10:30   ` Sagi Grimberg
2015-10-16  5:58 ` [PATCH 08/18] nvme: refactor nvme_queue_rq Christoph Hellwig
2015-10-16  5:58 ` [PATCH 09/18] nvme: move nvme_error_status to common code Christoph Hellwig
2015-10-20 10:54   ` Sagi Grimberg
2015-10-16  5:58 ` [PATCH 10/18] nvme: move nvme_setup_flush and nvme_setup_rw " Christoph Hellwig
2015-10-20 11:01   ` Sagi Grimberg
2015-10-21  6:55     ` Christoph Hellwig
2015-10-21 14:41       ` Sagi Grimberg
2015-10-16  5:58 ` [PATCH 11/18] nvme: split __nvme_submit_sync_cmd Christoph Hellwig
2015-10-16  5:58 ` [PATCH 12/18] nvme: use the block layer for userspace passthrough metadata Christoph Hellwig
2015-10-16 20:04   ` Busch, Keith
2015-10-18 18:22     ` Christoph Hellwig
2015-10-16  5:58 ` [PATCH 13/18] nvme: move block_device_operations and ns/ctrl freeing to common code Christoph Hellwig
2015-10-16  5:58 ` [PATCH 14/18] nvme: add explicit quirk handling Christoph Hellwig
2015-10-16  5:58 ` [PATCH 15/18] nvme: add a common helper to read Identify Controller data Christoph Hellwig
2015-10-21 22:44   ` J Freyensee
2015-10-22  7:38     ` Christoph Hellwig
2015-10-16  5:58 ` [PATCH 16/18] nvme: move the call to nvme_init_identify earlier Christoph Hellwig
2015-10-16  5:58 ` [PATCH 17/18] nvme: move namespace scanning to common code Christoph Hellwig
2015-10-16  6:14   ` Ming Lin
2015-10-16  6:16     ` Christoph Hellwig
2015-10-21 23:27   ` J Freyensee
2015-10-22  7:39     ` Christoph Hellwig
2015-10-22 13:48       ` Busch, Keith
2015-10-22 16:30         ` Christoph Hellwig
2015-10-22 21:24           ` Busch, Keith
2015-10-23  5:41             ` Christoph Hellwig
2015-10-16  5:58 ` [PATCH 18/18] nvme: move chardev and sysfs interface " Christoph Hellwig
2015-10-22  0:11   ` J Freyensee
2015-10-22  7:45     ` Christoph Hellwig
2015-10-22 18:36       ` J Freyensee
2015-10-22 18:59         ` Jon Derrick

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=20151022073714.GB20076@lst.de \
    --to=hch@lst.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).