From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Subject: Re: [RFC PATCH 00/28] Removing struct page from P2PDMA Date: Mon, 24 Jun 2019 15:54:44 -0300 Message-ID: <20190624185444.GD8268@ziepe.ca> References: <20190620161240.22738-1-logang@deltatee.com> <20190620193353.GF19891@ziepe.ca> <20190624073126.GB3954@lst.de> <20190624134641.GA8268@ziepe.ca> <20190624135024.GA11248@lst.de> <20190624135550.GB8268@ziepe.ca> <7210ba39-c923-79ca-57bb-7cf9afe21d54@deltatee.com> <20190624181632.GC8268@ziepe.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Logan Gunthorpe Cc: Christoph Hellwig , Dan Williams , Linux Kernel Mailing List , linux-block@vger.kernel.org, linux-nvme@lists.infradead.org, linux-pci@vger.kernel.org, linux-rdma , Jens Axboe , Bjorn Helgaas , Sagi Grimberg , Keith Busch , Stephen Bates List-Id: linux-rdma@vger.kernel.org On Mon, Jun 24, 2019 at 12:28:33PM -0600, Logan Gunthorpe wrote: > > Sounded like this series does generate the dma_addr for the correct > > device.. > > This series doesn't generate any DMA addresses with dma_map(). The > current p2pdma code ensures everything is behind the same root port and > only uses the pci bus address. This is valid and correct, but yes it's > something to expand upon. I think if you do this it still has to be presented as the same API like dma_map that takes in the target device * and produces the device specific dma_addr_t Otherwise this whole thing is confusing and looks like *all* of it can only work under the switch assumption Jason