[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190625071823.GA30350@lst.de>
Date: Tue, 25 Jun 2019 09:18:23 +0200
From: Christoph Hellwig <hch@....de>
To: Logan Gunthorpe <logang@...tatee.com>
Cc: Jason Gunthorpe <jgg@...pe.ca>, Christoph Hellwig <hch@....de>,
Dan Williams <dan.j.williams@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-block@...r.kernel.org, linux-nvme@...ts.infradead.org,
linux-pci@...r.kernel.org, linux-rdma <linux-rdma@...r.kernel.org>,
Jens Axboe <axboe@...nel.dk>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Sagi Grimberg <sagi@...mberg.me>,
Keith Busch <kbusch@...nel.org>,
Stephen Bates <sbates@...thlin.com>
Subject: Re: [RFC PATCH 00/28] Removing struct page from P2PDMA
On Mon, Jun 24, 2019 at 10:10:16AM -0600, Logan Gunthorpe wrote:
> Yes, that's correct. The intent was to invert it so the dma_map could
> happen at the start of the process so that P2PDMA code could be called
> with all the information it needs to make it's decision on how to map;
> without having to hook into the mapping process of every driver that
> wants to participate.
And that just isn't how things work in layering. We need to keep
generating the dma addresses in the driver in the receiving end, as
there are all kinds of interesting ideas how we do that. E.g. for the
Mellanox NICs addressing their own bars is not done by PCIe bus
addresses but by relative offsets. And while NVMe has refused to go
down that route in the current band aid fix for CMB addressing I suspect
it will sooner or later have to do the same to deal with the addressing
problems in a multiple PASID world.
Powered by blists - more mailing lists