From: J Freyensee <james_p_freyensee@linux.intel.com> To: Sagi Grimberg <sagi@grimberg.me>, Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk> Cc: Keith Busch <keith.busch@intel.com>, linux-block@vger.kernel.org, linux-nvme@lists.infradead.org Subject: Re: [PATCH 07/10] nvme: track shared namespaces Date: Mon, 28 Aug 2017 13:21:20 -0700 [thread overview] Message-ID: <1503951680.4860.3.camel@linux.intel.com> (raw) In-Reply-To: <bee7c6c3-bf6b-8f7e-ad8f-fd5e238a94ef@grimberg.me> On Mon, 2017-08-28 at 09:51 +0300, Sagi Grimberg wrote: > > On 23/08/17 20:58, Christoph Hellwig wrote: > > Introduce a new struct nvme_ns_head [1] that holds information about > > an actual namespace, unlike struct nvme_ns, which only holds the > > per-controller namespace information. For private namespaces there > > is a 1:1 relation of the two, but for shared namespaces this lets us > > discover all the paths to it. For now only the identifiers are moved > > to the new structure, but most of the information in struct nvme_ns > > should eventually move over. > > > > To allow lockless path lookup the list of nvme_ns structures per > > nvme_ns_head is protected by SRCU, which requires freeing the nvme_ns > > structure through call_srcu. > > I haven't read the later patches yet, but what requires sleep in the > path selection? > > > > > [1] comments welcome if you have a better name for it, the current one > > is > > horrible. One idea would be to rename the current struct nvme_ns > > to struct nvme_ns_link or similar and use the nvme_ns name for the > > new structure. But that would involve a lot of churn. > > maybe nvme_ns_primary? Since it looks like it holds all unique identifier values and should hold other namespace characteristics later, maybe: nvme_ns_item? Or nvme_ns_entry? Or nvme_ns_element? Or nvme_ns_unit? Or nvme_ns_entity? Or nvme_ns_container? > > +/* > > + * Anchor structure for namespaces. There is one for each namespace > > in a > > + * NVMe subsystem that any of our controllers can see, and the > > namespace > > + * structure for each controller is chained of it. For private > > namespaces > > + * there is a 1:1 relation to our namespace structures, that is ->list > > + * only ever has a single entry for private namespaces. > > + */ > > +struct nvme_ns_head { > > + struct list_head list; > > Maybe siblings is a better name than list, > and the nvme_ns list_head should be called > sibling_entry (or just sibling)? I think that sounds good too. > > > + struct srcu_struct srcu; > > + unsigned ns_id; > > + u8 eui64[8]; > > + u8 nguid[16]; > > + uuid_t uuid; > > + struct list_head entry; > > + struct kref ref; > > +}; > > + > > struct nvme_ns { > > struct list_head list; > > > > struct nvme_ctrl *ctrl; > > struct request_queue *queue; > > struct gendisk *disk; > > + struct list_head siblings; > > struct nvm_dev *ndev; > > struct kref kref; > > + struct nvme_ns_head *head; > > int instance; > > > > - u8 eui[8]; > > - u8 nguid[16]; > > - uuid_t uuid; > > - > > - unsigned ns_id; > > int lba_shift; > > u16 ms; > > u16 sgs; > > > >
WARNING: multiple messages have this Message-ID (diff)
From: james_p_freyensee@linux.intel.com (J Freyensee) Subject: [PATCH 07/10] nvme: track shared namespaces Date: Mon, 28 Aug 2017 13:21:20 -0700 [thread overview] Message-ID: <1503951680.4860.3.camel@linux.intel.com> (raw) In-Reply-To: <bee7c6c3-bf6b-8f7e-ad8f-fd5e238a94ef@grimberg.me> On Mon, 2017-08-28@09:51 +0300, Sagi Grimberg wrote: > > On 23/08/17 20:58, Christoph Hellwig wrote: > > Introduce a new struct nvme_ns_head [1] that holds information about > > an actual namespace, unlike struct nvme_ns, which only holds the > > per-controller namespace information.??For private namespaces there > > is a 1:1 relation of the two, but for shared namespaces this lets us > > discover all the paths to it.??For now only the identifiers are moved > > to the new structure, but most of the information in struct nvme_ns > > should eventually move over. > > > > To allow lockless path lookup the list of nvme_ns structures per > > nvme_ns_head is protected by SRCU, which requires freeing the nvme_ns > > structure through call_srcu. > > I haven't read the later patches yet, but what requires sleep in the > path selection? > > > > > [1] comments welcome if you have a better name for it, the current one > > is > > ?????horrible.??One idea would be to rename the current struct nvme_ns > > ?????to struct nvme_ns_link or similar and use the nvme_ns name for the > > ?????new structure.??But that would involve a lot of churn. > > maybe nvme_ns_primary? Since it looks like it holds all unique identifier values and should hold other namespace characteristics later, maybe: nvme_ns_item? Or nvme_ns_entry? Or nvme_ns_element? Or nvme_ns_unit? Or nvme_ns_entity? Or nvme_ns_container? > > +/* > > + * Anchor structure for namespaces.??There is one for each namespace > > in a > > + * NVMe subsystem that any of our controllers can see, and the > > namespace > > + * structure for each controller is chained of it.??For private > > namespaces > > + * there is a 1:1 relation to our namespace structures, that is ->list > > + * only ever has a single entry for private namespaces. > > + */ > > +struct nvme_ns_head { > > + struct list_head list; > > Maybe siblings is a better name than list, > and the nvme_ns list_head should be called > sibling_entry (or just sibling)? I think that sounds good too. > > > + struct srcu_struct??????srcu; > > + unsigned ns_id; > > + u8 eui64[8]; > > + u8 nguid[16]; > > + uuid_t uuid; > > + struct list_head entry; > > + struct kref ref; > > +}; > > + > > ? struct nvme_ns { > > ?? struct list_head list; > > ?? > > ?? struct nvme_ctrl *ctrl; > > ?? struct request_queue *queue; > > ?? struct gendisk *disk; > > + struct list_head siblings; > > ?? struct nvm_dev *ndev; > > ?? struct kref kref; > > + struct nvme_ns_head *head; > > ?? int instance; > > ?? > > - u8 eui[8]; > > - u8 nguid[16]; > > - uuid_t uuid; > > - > > - unsigned ns_id; > > ?? int lba_shift; > > ?? u16 ms; > > ?? u16 sgs; > > > >
next prev parent reply other threads:[~2017-08-28 20:21 UTC|newest] Thread overview: 122+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-08-23 17:58 RFC: nvme multipath support Christoph Hellwig 2017-08-23 17:58 ` Christoph Hellwig 2017-08-23 17:58 ` [PATCH 01/10] nvme: report more detailed status codes to the block layer Christoph Hellwig 2017-08-23 17:58 ` Christoph Hellwig 2017-08-28 6:06 ` Sagi Grimberg 2017-08-28 6:06 ` Sagi Grimberg 2017-08-28 18:50 ` Keith Busch 2017-08-28 18:50 ` Keith Busch 2017-08-23 17:58 ` [PATCH 02/10] nvme: allow calling nvme_change_ctrl_state from irq context Christoph Hellwig 2017-08-23 17:58 ` Christoph Hellwig 2017-08-28 6:06 ` Sagi Grimberg 2017-08-28 6:06 ` Sagi Grimberg 2017-08-28 18:50 ` Keith Busch 2017-08-28 18:50 ` Keith Busch 2017-08-23 17:58 ` [PATCH 03/10] nvme: remove unused struct nvme_ns fields Christoph Hellwig 2017-08-23 17:58 ` Christoph Hellwig 2017-08-28 6:07 ` Sagi Grimberg 2017-08-28 6:07 ` Sagi Grimberg 2017-08-28 19:13 ` Keith Busch 2017-08-28 19:13 ` Keith Busch 2017-08-23 17:58 ` [PATCH 04/10] nvme: remove nvme_revalidate_ns Christoph Hellwig 2017-08-23 17:58 ` Christoph Hellwig 2017-08-28 6:12 ` Sagi Grimberg 2017-08-28 6:12 ` Sagi Grimberg 2017-08-28 19:14 ` Keith Busch 2017-08-28 19:14 ` Keith Busch 2017-08-23 17:58 ` [PATCH 05/10] nvme: don't blindly overwrite identifiers on disk revalidate Christoph Hellwig 2017-08-23 17:58 ` Christoph Hellwig 2017-08-28 6:17 ` Sagi Grimberg 2017-08-28 6:17 ` Sagi Grimberg 2017-08-28 6:23 ` Christoph Hellwig 2017-08-28 6:23 ` Christoph Hellwig 2017-08-28 6:32 ` Sagi Grimberg 2017-08-28 6:32 ` Sagi Grimberg 2017-08-28 19:15 ` Keith Busch 2017-08-28 19:15 ` Keith Busch 2017-08-23 17:58 ` [PATCH 06/10] nvme: track subsystems Christoph Hellwig 2017-08-23 17:58 ` Christoph Hellwig 2017-08-23 22:04 ` Keith Busch 2017-08-23 22:04 ` Keith Busch 2017-08-24 8:52 ` Christoph Hellwig 2017-08-24 8:52 ` Christoph Hellwig 2017-08-28 6:22 ` Sagi Grimberg 2017-08-28 6:22 ` Sagi Grimberg 2017-08-23 17:58 ` [PATCH 07/10] nvme: track shared namespaces Christoph Hellwig 2017-08-23 17:58 ` Christoph Hellwig 2017-08-28 6:51 ` Sagi Grimberg 2017-08-28 6:51 ` Sagi Grimberg 2017-08-28 8:50 ` Christoph Hellwig 2017-08-28 8:50 ` Christoph Hellwig 2017-08-28 20:21 ` J Freyensee [this message] 2017-08-28 20:21 ` J Freyensee 2017-08-29 8:25 ` Christoph Hellwig 2017-08-29 8:25 ` Christoph Hellwig 2017-08-29 6:54 ` Guan Junxiong 2017-08-29 6:54 ` Guan Junxiong 2017-08-28 12:04 ` javigon 2017-08-28 12:04 ` javigon 2017-08-28 12:41 ` Guan Junxiong 2017-08-28 12:41 ` Guan Junxiong 2017-08-28 14:30 ` Christoph Hellwig 2017-08-28 14:30 ` Christoph Hellwig 2017-08-29 2:42 ` Guan Junxiong 2017-08-29 2:42 ` Guan Junxiong 2017-08-29 8:30 ` Christoph Hellwig 2017-08-29 8:30 ` Christoph Hellwig 2017-08-29 8:29 ` Christoph Hellwig 2017-08-29 8:29 ` Christoph Hellwig 2017-08-28 19:18 ` Keith Busch 2017-08-28 19:18 ` Keith Busch 2017-08-23 17:58 ` [PATCH 08/10] block: provide a generic_make_request_fast helper Christoph Hellwig 2017-08-23 17:58 ` Christoph Hellwig 2017-08-28 7:00 ` Sagi Grimberg 2017-08-28 7:00 ` Sagi Grimberg 2017-08-28 8:54 ` Christoph Hellwig 2017-08-28 8:54 ` Christoph Hellwig 2017-08-28 11:01 ` Sagi Grimberg 2017-08-28 11:01 ` Sagi Grimberg 2017-08-28 11:54 ` Christoph Hellwig 2017-08-28 11:54 ` Christoph Hellwig 2017-08-28 12:38 ` Sagi Grimberg 2017-08-28 12:38 ` Sagi Grimberg 2017-08-23 17:58 ` [PATCH 09/10] blk-mq: add a blk_steal_bios helper Christoph Hellwig 2017-08-23 17:58 ` Christoph Hellwig 2017-08-28 7:04 ` Sagi Grimberg 2017-08-28 7:04 ` Sagi Grimberg 2017-08-23 17:58 ` [PATCH 10/10] nvme: implement multipath access to nvme subsystems Christoph Hellwig 2017-08-23 17:58 ` Christoph Hellwig 2017-08-23 18:21 ` Bart Van Assche 2017-08-23 18:21 ` Bart Van Assche 2017-08-24 8:59 ` hch 2017-08-24 8:59 ` hch 2017-08-24 20:17 ` Bart Van Assche 2017-08-24 20:17 ` Bart Van Assche 2017-09-05 11:53 ` Christoph Hellwig 2017-09-05 11:53 ` Christoph Hellwig 2017-09-11 6:34 ` Tony Yang 2017-08-23 22:53 ` Keith Busch 2017-08-23 22:53 ` Keith Busch 2017-08-24 8:52 ` Christoph Hellwig 2017-08-24 8:52 ` Christoph Hellwig 2017-08-28 7:23 ` Sagi Grimberg 2017-08-28 7:23 ` Sagi Grimberg 2017-08-28 9:06 ` Christoph Hellwig 2017-08-28 9:06 ` Christoph Hellwig 2017-08-28 13:40 ` Sagi Grimberg 2017-08-28 13:40 ` Sagi Grimberg 2017-08-28 14:24 ` Christoph Hellwig 2017-08-28 14:24 ` Christoph Hellwig 2017-09-07 15:17 ` Tony Yang 2017-08-29 10:22 ` Guan Junxiong 2017-08-29 10:22 ` Guan Junxiong 2017-08-29 14:51 ` Christoph Hellwig 2017-08-29 14:51 ` Christoph Hellwig 2017-08-29 14:54 ` Keith Busch 2017-08-29 14:54 ` Keith Busch 2017-08-29 14:55 ` Christoph Hellwig 2017-08-29 14:55 ` Christoph Hellwig 2017-08-29 15:41 ` Keith Busch 2017-08-29 15:41 ` Keith Busch 2017-09-18 0:17 ` Christoph Hellwig 2017-09-18 0:17 ` Christoph Hellwig
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=1503951680.4860.3.camel@linux.intel.com \ --to=james_p_freyensee@linux.intel.com \ --cc=axboe@kernel.dk \ --cc=hch@lst.de \ --cc=keith.busch@intel.com \ --cc=linux-block@vger.kernel.org \ --cc=linux-nvme@lists.infradead.org \ --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: linkBe 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.