linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Bates <Stephen.Bates@pmcs.com>
To: Logan Gunthorpe <logang@deltatee.com>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	Matthew Wilcox <willy@linux.intel.com>
Cc: "haggaie@mellanox.com" <haggaie@mellanox.com>,
	"javier@cnexlabs.com" <javier@cnexlabs.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"linux-nvdimm@ml01.01.org" <linux-nvdimm@ml01.01.org>,
	"sagig@mellanox.com" <sagig@mellanox.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"artemyko@mellanox.com" <artemyko@mellanox.com>,
	"hch@infradead.org" <hch@infradead.org>,
	"leonro@mellanox.com" <leonro@mellanox.com>
Subject: RE: [PATCH RFC 1/1] Add support for ZONE_DEVICE IO memory with struct pages.
Date: Tue, 15 Mar 2016 17:00:34 +0000	[thread overview]
Message-ID: <36F6EBABA23FEF4391AF72944D228901EB7280F2@BBYEXM01.pmc-sierra.internal> (raw)
In-Reply-To: <56E78B08.8050205@deltatee.com>

> 
> On 14/03/16 03:57 PM, Jason Gunthorpe wrote:
> > Someone should probably explain in more detail what this is even good
> > for, DAX on PCI-E bar memory seems goofy in the general case. I was
> > under the impression the main use case involved the CPU never touching
> > these memories and just using them to route-through to another IO
> > device (eg network). So all these discussions about CPU coherency seem
> > a bit strange.
> 
> 
> Yes, the primary purpose is to enable P2P transactions that don't involve the
> CPU at all. To enable this, we do mmap the BAR region into user space which
> is then technically able to read/write to it using the CPU. However, you're
> right, it is silly to write to the mmap'd PCI BAR for anything but debug/testing
> purposes -- this type of access also has horrible performance. Really, the
> mmaping is just a convenient way to pass around the addresses with existing
> interfaces that expect system RAM (RDMA, O_DIRECT).
> 
> Putting DAX on the PCI-E bar is a actually more of a curiosity at the moment
> than anything. The current plan for NVMe with CMB would not involve DAX.
> CMB buffers would be allocated perhaps by mapping the nvmeX char device
> which could then be used with O_DIRECT access on a file on the NVME
> device and also be passed to RDMA devices. In this way data could flow from
> the NVMe device to an RDMA network without using system memory to
> buffer it.
> 
> Logan

The transfer of data between PCIe devices is the main use-case for this proposed patch.

Some other applications for this include direct transfer of data between PCIe SSDs (for background data movement and replication) and the movement of data between PCIe SSDs and GPGPU/FPGAs for accelerating applications that use those types of offload engines. In some of our performance tests we have seen significant reduction in residual DRAM bandwidth when all the data involved in these transfers has to pass through system memory buffers. This proposed patch avoids that problem.

Stephen

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-03-15 17:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-14 18:14 Stephen Bates
2016-03-14 21:23 ` Matthew Wilcox
2016-03-14 21:57   ` Jason Gunthorpe
2016-03-15  4:09     ` Logan Gunthorpe
2016-03-15 17:00       ` Stephen Bates [this message]
2016-03-17 15:18     ` Haggai Eran
2016-03-17 16:11       ` Jason Gunthorpe
2016-03-21 19:25         ` Stephen Bates

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=36F6EBABA23FEF4391AF72944D228901EB7280F2@BBYEXM01.pmc-sierra.internal \
    --to=stephen.bates@pmcs.com \
    --cc=artemyko@mellanox.com \
    --cc=haggaie@mellanox.com \
    --cc=hch@infradead.org \
    --cc=javier@cnexlabs.com \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=leonro@mellanox.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@ml01.01.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=sagig@mellanox.com \
    --cc=willy@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox