From: Keith Busch <keith.busch@linux.intel.com>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
linux-nvme@lists.infradead.org, linux-rdma@vger.kernel.org,
linux-nvdimm@lists.01.org, linux-block@vger.kernel.org,
"Jens Axboe" <axboe@kernel.dk>,
"Christian König" <christian.koenig@amd.com>,
"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Jason Gunthorpe" <jgg@mellanox.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Max Gurtovoy" <maxg@mellanox.com>,
"Christoph Hellwig" <hch@lst.de>
Subject: Re: [PATCH v8 09/13] nvme-pci: Use PCI p2pmem subsystem to manage the CMB
Date: Thu, 27 Sep 2018 11:10:13 -0600 [thread overview]
Message-ID: <20180927171013.GC19589@localhost.localdomain> (raw)
In-Reply-To: <20180927165420.5290-10-logang@deltatee.com>
On Thu, Sep 27, 2018 at 10:54:16AM -0600, Logan Gunthorpe wrote:
> Register the CMB buffer as p2pmem and use the appropriate allocation
> functions to create and destroy the IO submission queues.
>
> If the CMB supports WDS and RDS, publish it for use as P2P memory
> by other devices.
>
> Kernels without CONFIG_PCI_P2PDMA will also no longer support NVMe CMB.
> However, seeing the main use-cases for the CMB is P2P operations,
> this seems like a reasonable dependency.
>
> We drop the __iomem safety on the buffer seeing that, by convention, it's
> safe to directly access memory mapped by memremap()/devm_memremap_pages().
> Architectures where this is not safe will not be supported by memremap()
> and therefore will not be support PCI P2P and have no support for CMB.
>
> Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Looks good to me.
Reviewed-by: Keith Busch <keith.busch@intel.com>
WARNING: multiple messages have this Message-ID (diff)
From: Keith Busch <keith.busch@linux.intel.com>
To: Logan Gunthorpe <logang@deltatee.com>
Cc: "Jens Axboe" <axboe@kernel.dk>,
linux-nvdimm@lists.01.org, linux-rdma@vger.kernel.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-nvme@lists.infradead.org, "Christoph Hellwig" <hch@lst.de>,
linux-block@vger.kernel.org,
"Alex Williamson" <alex.williamson@redhat.com>,
"Jason Gunthorpe" <jgg@mellanox.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Max Gurtovoy" <maxg@mellanox.com>,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH v8 09/13] nvme-pci: Use PCI p2pmem subsystem to manage the CMB
Date: Thu, 27 Sep 2018 11:10:13 -0600 [thread overview]
Message-ID: <20180927171013.GC19589@localhost.localdomain> (raw)
In-Reply-To: <20180927165420.5290-10-logang@deltatee.com>
On Thu, Sep 27, 2018 at 10:54:16AM -0600, Logan Gunthorpe wrote:
> Register the CMB buffer as p2pmem and use the appropriate allocation
> functions to create and destroy the IO submission queues.
>
> If the CMB supports WDS and RDS, publish it for use as P2P memory
> by other devices.
>
> Kernels without CONFIG_PCI_P2PDMA will also no longer support NVMe CMB.
> However, seeing the main use-cases for the CMB is P2P operations,
> this seems like a reasonable dependency.
>
> We drop the __iomem safety on the buffer seeing that, by convention, it's
> safe to directly access memory mapped by memremap()/devm_memremap_pages().
> Architectures where this is not safe will not be supported by memremap()
> and therefore will not be support PCI P2P and have no support for CMB.
>
> Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Looks good to me.
Reviewed-by: Keith Busch <keith.busch@intel.com>
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: keith.busch@linux.intel.com (Keith Busch)
Subject: [PATCH v8 09/13] nvme-pci: Use PCI p2pmem subsystem to manage the CMB
Date: Thu, 27 Sep 2018 11:10:13 -0600 [thread overview]
Message-ID: <20180927171013.GC19589@localhost.localdomain> (raw)
In-Reply-To: <20180927165420.5290-10-logang@deltatee.com>
On Thu, Sep 27, 2018@10:54:16AM -0600, Logan Gunthorpe wrote:
> Register the CMB buffer as p2pmem and use the appropriate allocation
> functions to create and destroy the IO submission queues.
>
> If the CMB supports WDS and RDS, publish it for use as P2P memory
> by other devices.
>
> Kernels without CONFIG_PCI_P2PDMA will also no longer support NVMe CMB.
> However, seeing the main use-cases for the CMB is P2P operations,
> this seems like a reasonable dependency.
>
> We drop the __iomem safety on the buffer seeing that, by convention, it's
> safe to directly access memory mapped by memremap()/devm_memremap_pages().
> Architectures where this is not safe will not be supported by memremap()
> and therefore will not be support PCI P2P and have no support for CMB.
>
> Signed-off-by: Logan Gunthorpe <logang at deltatee.com>
Looks good to me.
Reviewed-by: Keith Busch <keith.busch at intel.com>
WARNING: multiple messages have this Message-ID (diff)
From: Keith Busch <keith.busch-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
Cc: "Jens Axboe" <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
"Christoph Hellwig" <hch-jcswGhMUV9g@public.gmane.org>,
linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Alex Williamson"
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"Jason Gunthorpe" <jgg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
"Jérôme Glisse" <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"Benjamin Herrenschmidt"
<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>,
"Bjorn Helgaas"
<bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
"Max Gurtovoy" <maxg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>,
"Christian König" <christian.koenig-5C7GfCeVMHo@public.gmane.org>
Subject: Re: [PATCH v8 09/13] nvme-pci: Use PCI p2pmem subsystem to manage the CMB
Date: Thu, 27 Sep 2018 11:10:13 -0600 [thread overview]
Message-ID: <20180927171013.GC19589@localhost.localdomain> (raw)
In-Reply-To: <20180927165420.5290-10-logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
On Thu, Sep 27, 2018 at 10:54:16AM -0600, Logan Gunthorpe wrote:
> Register the CMB buffer as p2pmem and use the appropriate allocation
> functions to create and destroy the IO submission queues.
>
> If the CMB supports WDS and RDS, publish it for use as P2P memory
> by other devices.
>
> Kernels without CONFIG_PCI_P2PDMA will also no longer support NVMe CMB.
> However, seeing the main use-cases for the CMB is P2P operations,
> this seems like a reasonable dependency.
>
> We drop the __iomem safety on the buffer seeing that, by convention, it's
> safe to directly access memory mapped by memremap()/devm_memremap_pages().
> Architectures where this is not safe will not be supported by memremap()
> and therefore will not be support PCI P2P and have no support for CMB.
>
> Signed-off-by: Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
Looks good to me.
Reviewed-by: Keith Busch <keith.busch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
next prev parent reply other threads:[~2018-09-27 17:10 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-27 16:54 [PATCH v8 00/13] Copy Offload in NVMe Fabrics with P2P PCI Memory Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` [PATCH v8 01/13] PCI/P2PDMA: Support peer-to-peer memory Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` [PATCH v8 02/13] PCI/P2PDMA: Add sysfs group to display p2pmem stats Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` [PATCH v8 03/13] PCI/P2PDMA: Add PCI p2pmem DMA mappings to adjust the bus offset Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` [PATCH v8 04/13] PCI/P2PDMA: Introduce configfs/sysfs enable attribute helpers Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` [PATCH v8 05/13] docs-rst: Add a new directory for PCI documentation Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` [PATCH v8 06/13] PCI/P2PDMA: Add P2P DMA driver writer's documentation Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` [PATCH v8 07/13] block: Add PCI P2P flag for request queue and check support for requests Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` [PATCH v8 08/13] IB/core: Ensure we map P2P memory correctly in rdma_rw_ctx_[init|destroy]() Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` [PATCH v8 09/13] nvme-pci: Use PCI p2pmem subsystem to manage the CMB Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 17:10 ` Keith Busch [this message]
2018-09-27 17:10 ` Keith Busch
2018-09-27 17:10 ` Keith Busch
2018-09-27 17:10 ` Keith Busch
2018-09-27 16:54 ` [PATCH v8 10/13] nvme-pci: Add support for P2P memory in requests Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 17:10 ` Keith Busch
2018-09-27 17:10 ` Keith Busch
2018-09-27 17:10 ` Keith Busch
2018-09-27 16:54 ` [PATCH v8 11/13] nvme-pci: Add a quirk for a pseudo CMB Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 17:09 ` Keith Busch
2018-09-27 17:09 ` Keith Busch
2018-09-27 17:09 ` Keith Busch
2018-09-27 17:09 ` Keith Busch
2018-09-27 16:54 ` [PATCH v8 12/13] nvmet: Introduce helper functions to allocate and free request SGLs Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` [PATCH v8 13/13] nvmet: Optionally use PCI P2P memory Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 16:54 ` Logan Gunthorpe
2018-09-27 17:12 ` Keith Busch
2018-09-27 17:12 ` Keith Busch
2018-09-27 17:12 ` Keith Busch
2018-09-27 17:12 ` Keith Busch
2018-09-27 17:29 ` Logan Gunthorpe
2018-09-27 17:29 ` Logan Gunthorpe
2018-09-27 17:29 ` Logan Gunthorpe
2018-09-27 17:29 ` Logan Gunthorpe
2018-10-01 21:34 ` Sagi Grimberg
2018-10-01 21:34 ` Sagi Grimberg
2018-10-01 21:34 ` Sagi Grimberg
2018-10-01 21:34 ` Sagi Grimberg
2018-10-01 21:55 ` Logan Gunthorpe
2018-10-01 21:55 ` Logan Gunthorpe
2018-10-01 21:55 ` Logan Gunthorpe
2018-10-01 21:55 ` Logan Gunthorpe
2018-10-01 22:23 ` Sagi Grimberg
2018-10-01 22:23 ` Sagi Grimberg
2018-10-01 22:23 ` Sagi Grimberg
2018-10-01 22:23 ` Sagi Grimberg
2018-10-01 23:43 ` Logan Gunthorpe
2018-10-01 23:43 ` Logan Gunthorpe
2018-10-01 23:43 ` Logan Gunthorpe
2018-10-01 23:43 ` 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=20180927171013.GC19589@localhost.localdomain \
--to=keith.busch@linux.intel.com \
--cc=alex.williamson@redhat.com \
--cc=axboe@kernel.dk \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=christian.koenig@amd.com \
--cc=hch@lst.de \
--cc=jgg@mellanox.com \
--cc=jglisse@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=maxg@mellanox.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.