From: james_p_freyensee@linux.intel.com (J Freyensee)
Subject: [PATCH 06/18] nvme: split a new struct nvme_ctrl out of struct nvme_dev
Date: Wed, 21 Oct 2015 14:23:46 -0700 [thread overview]
Message-ID: <1445462626.3307.64.camel@linux.intel.com> (raw)
In-Reply-To: <1444975128-8768-7-git-send-email-hch@lst.de>
On Fri, 2015-10-16@07:58 +0200, Christoph Hellwig wrote:
> The new struct nvme_ctrl will be used by the common NVMe code that
> sits
> on top of struct request_queue and the new nvme_ctrl_ops abstraction.
> It only contains the bare minimum required, which consists of values
> sampled during controller probe, the admin queue pointer and a second
> struct device pointer at the moment, but more will follow later.
> Only
> values that are not used in the I/O fast path should be moved to
> struct nvme_ctrl so that drivers can optimize their cache line usage
> easily. That's also the reason why we have two device pointers as
> the struct device is used for DMA mapping purposes.
>
> Signed-off-by: Christoph Hellwig <hch at lst.de>
> Acked-by: Keith Busch <keith.busch at intel.com>
> ---
> drivers/nvme/host/core.c | 10 +--
> drivers/nvme/host/nvme.h | 61 ++++++---------
> drivers/nvme/host/pci.c | 190 +++++++++++++++++++++++++++++++------
> ----------
> drivers/nvme/host/scsi.c | 85 ++++++++++-----------
> 4 files changed, 190 insertions(+), 156 deletions(-)
>
<snipped>
> diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> index 370aa5b..3e409fa 100644
> --- a/drivers/nvme/host/nvme.h
> +++ b/drivers/nvme/host/nvme.h
> @@ -25,46 +25,16 @@ extern unsigned char nvme_io_timeout;
> extern unsigned char admin_timeout;
> #define ADMIN_TIMEOUT (admin_timeout * HZ)
>
> -/*
> - * Represents an NVM Express device. Each nvme_dev is a PCI
> function.
> - */
> -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.
> + const struct nvme_ctrl_ops *ops;
> struct request_queue *admin_q;
> - struct blk_mq_tag_set tagset;
> - struct blk_mq_tag_set admin_tagset;
> - u32 __iomem *dbs;
> struct device *dev;
> - struct dma_pool *prp_page_pool;
> - struct dma_pool *prp_small_pool;
> int instance;
> - unsigned queue_count;
> - unsigned online_queues;
> - unsigned max_qid;
> - int q_depth;
> - u32 db_stride;
> - u32 ctrl_config;
> - struct msix_entry *entry;
> - void __iomem *bar;
> - struct list_head namespaces;
> - struct kref kref;
> - struct device *device;
> - struct work_struct reset_work;
> - struct work_struct probe_work;
> - struct work_struct scan_work;
> +
> char name[12];
> char serial[20];
> char model[40];
> char firmware_rev[8];
> - 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.
> - u32 max_hw_sectors;
> - u32 stripe_size;
> - u32 page_size;
> - void __iomem *cmb;
> - dma_addr_t cmb_dma_addr;
> - u64 cmb_size;
> - u32 cmbsz;
> u16 oncs;
> u16 abort_limit;
> u8 event_limit;
> @@ -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.
> struct request_queue *queue;
> struct gendisk *disk;
> struct kref kref;
> @@ -92,6 +62,19 @@ struct nvme_ns {
> u32 mode_select_block_len;
> };
>
next prev parent reply other threads:[~2015-10-21 21:23 UTC|newest]
Thread overview: 62+ 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-16 5:58 ` Christoph Hellwig
2015-10-20 10:04 ` Sagi Grimberg
2015-10-20 10:04 ` Sagi Grimberg
2015-10-20 14:07 ` Busch, Keith
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 [this message]
2015-10-21 22:51 ` Busch, Keith
2015-10-22 0:15 ` J Freyensee
2015-10-22 7:37 ` Christoph Hellwig
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=1445462626.3307.64.camel@linux.intel.com \
--to=james_p_freyensee@linux.intel.com \
/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.