Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753025AbcLFQwM (ORCPT ); Tue, 6 Dec 2016 11:52:12 -0500 Received: from ale.deltatee.com ([207.54.116.67]:49201 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751670AbcLFQwJ (ORCPT ); Tue, 6 Dec 2016 11:52:09 -0500 To: Jason Gunthorpe , Stephen Bates References: <5f5b7989-84f5-737e-47c8-831f752d6280@deltatee.com> <61a2fb07344aacd81111449d222de66e.squirrel@webmail.raithlin.com> <20161205171830.GB27784@obsidianresearch.com> <20161205180231.GA28133@obsidianresearch.com> <20161206163850.GC28066@obsidianresearch.com> Cc: Dan Williams , Haggai Eran , "linux-kernel@vger.kernel.org" , "linux-rdma@vger.kernel.org" , "linux-nvdimm@ml01.01.org" , "christian.koenig@amd.com" , "Suravee.Suthikulpanit@amd.com" , "John.Bridgman@amd.com" , "Alexander.Deucher@amd.com" , "Linux-media@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , Max Gurtovoy , "linux-pci@vger.kernel.org" , "serguei.sagalovitch@amd.com" , "Paul.Blinzer@amd.com" , "Felix.Kuehling@amd.com" , "ben.sander@amd.com" From: Logan Gunthorpe Message-ID: Date: Tue, 6 Dec 2016 09:51:15 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161206163850.GC28066@obsidianresearch.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.111 X-SA-Exim-Rcpt-To: ben.sander@amd.com, felix.kuehling@amd.com, paul.blinzer@amd.com, serguei.sagalovitch@amd.com, linux-pci@vger.kernel.org, maxg@mellanox.com, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org, alexander.deucher@amd.com, john.bridgman@amd.com, suravee.suthikulpanit@amd.com, christian.koenig@amd.com, linux-nvdimm@ml01.01.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, haggaie@mellanox.com, dan.j.williams@intel.com, sbates@raithlin.com, jgunthorpe@obsidianresearch.com X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: Enabling peer to peer device transactions for PCIe devices X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1592 Lines: 35 Hey, On 06/12/16 09:38 AM, Jason Gunthorpe wrote: >>> I'm not opposed to mapping /dev/nvmeX. However, the lookup is trivial >>> to accomplish in sysfs through /sys/dev/char to find the sysfs path of the >>> device-dax instance under the nvme device, or if you already have the nvme >>> sysfs path the dax instance(s) will appear under the "dax" sub-directory. >> >> Personally I think mapping the dax resource in the sysfs tree is a nice >> way to do this and a bit more intuitive than mapping a /dev/nvmeX. > > It is still not at all clear to me what userpsace is supposed to do > with this on nvme.. How is the CMB usable from userspace? The flow is pretty simple. For example to write to NVMe from an RDMA device: 1) Obtain a chunk of the CMB to use as a buffer(either by mmaping /dev/nvmx, the device dax char device or through a block layer interface (which sounds like a good suggestion from Christoph, but I'm not really sure how it would look). 2) Create an MR with the buffer and use an RDMA function to fill it with data from a remote host. This will cause the RDMA hardware to write directly to the memory in the NVMe card. 3) Using O_DIRECT, write the buffer to a file on the NVMe filesystem. When the address reaches hardware the NVMe will recognize it as local memory and copy it directly there. Thus we are able to transfer data to any file on an NVMe device without going through system memory. This has benefits on systems with lots of activity in system memory but step 3 is likely to be slowish due to the need to pin/unpin the memory for every transaction. Logan