From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Williams Subject: Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory Date: Tue, 18 Apr 2017 15:52:08 -0700 Message-ID: References: <1492381396.25766.43.camel@kernel.crashing.org> <20170418164557.GA7181@obsidianresearch.com> <1492555569.25766.99.camel@kernel.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <1492555569.25766.99.camel@kernel.crashing.org> Sender: linux-scsi-owner@vger.kernel.org To: Benjamin Herrenschmidt Cc: Jason Gunthorpe , Logan Gunthorpe , Bjorn Helgaas , Christoph Hellwig , Sagi Grimberg , "James E.J. Bottomley" , "Martin K. Petersen" , Jens Axboe , Steve Wise , Stephen Bates , Max Gurtovoy , Keith Busch , linux-pci@vger.kernel.org, linux-scsi , linux-nvme@lists.infradead.org, linux-rdma@vger.kernel.org, linux-nvdimm , "linux-kernel@vger.kernel.org" , Jerome Glisse List-Id: linux-nvdimm@lists.01.org On Tue, Apr 18, 2017 at 3:46 PM, Benjamin Herrenschmidt wrote: > On Tue, 2017-04-18 at 10:27 -0700, Dan Williams wrote: >> > FWIW, RDMA probably wouldn't want to use a p2mem device either, we >> > already have APIs that map BAR memory to user space, and would like to >> > keep using them. A 'enable P2P for bar' helper function sounds better >> > to me. >> >> ...and I think it's not a helper function as much as asking the bus >> provider "can these two device dma to each other". The "helper" is the >> dma api redirecting through a software-iommu that handles bus address >> translation differently than it would handle host memory dma mapping. > > Do we even need tat function ? The dma_ops have a dma_supported() > call... > > If we have those override ops built into the "dma_target" object, > then these things can make that decision knowing both the source > and target device. > Yes. From mboxrd@z Thu Jan 1 00:00:00 1970 From: dan.j.williams@intel.com (Dan Williams) Date: Tue, 18 Apr 2017 15:52:08 -0700 Subject: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory In-Reply-To: <1492555569.25766.99.camel@kernel.crashing.org> References: <1492381396.25766.43.camel@kernel.crashing.org> <20170418164557.GA7181@obsidianresearch.com> <1492555569.25766.99.camel@kernel.crashing.org> Message-ID: On Tue, Apr 18, 2017 at 3:46 PM, Benjamin Herrenschmidt wrote: > On Tue, 2017-04-18@10:27 -0700, Dan Williams wrote: >> > FWIW, RDMA probably wouldn't want to use a p2mem device either, we >> > already have APIs that map BAR memory to user space, and would like to >> > keep using them. A 'enable P2P for bar' helper function sounds better >> > to me. >> >> ...and I think it's not a helper function as much as asking the bus >> provider "can these two device dma to each other". The "helper" is the >> dma api redirecting through a software-iommu that handles bus address >> translation differently than it would handle host memory dma mapping. > > Do we even need tat function ? The dma_ops have a dma_supported() > call... > > If we have those override ops built into the "dma_target" object, > then these things can make that decision knowing both the source > and target device. > Yes.