[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7d276107-d2ae-530b-3d56-e104e22b4eea@deltatee.com>
Date: Mon, 8 Jan 2018 12:05:57 -0700
From: Logan Gunthorpe <logang@...tatee.com>
To: Christoph Hellwig <hch@....de>
Cc: Jason Gunthorpe <jgg@...pe.ca>, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org, linux-nvme@...ts.infradead.org,
linux-rdma@...r.kernel.org, linux-nvdimm@...ts.01.org,
linux-block@...r.kernel.org, Stephen Bates <sbates@...thlin.com>,
Jens Axboe <axboe@...nel.dk>,
Keith Busch <keith.busch@...el.com>,
Sagi Grimberg <sagi@...mberg.me>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Max Gurtovoy <maxg@...lanox.com>,
Dan Williams <dan.j.williams@...el.com>,
Jérôme Glisse <jglisse@...hat.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [PATCH 06/12] IB/core: Add optional PCI P2P flag to
rdma_rw_ctx_[init|destroy]()
On 08/01/18 11:57 AM, Christoph Hellwig wrote:
> It does, sort of - but in a different way then the normal DMA map
> ops. And only to work around the fact that we need to map our
> P2P space into struct pages. Without that we could just pass the
> bus address around, but the Linux stack and VM isn't anywhere near
> ready for something that advanced.
Yeah, wouldn't that be nice.
Ok, so if we shouldn't touch the dma_map infrastructure how should the
workaround to opt-out HFI and QIB look? I'm not that familiar with the
RDMA code.
Thanks,
Logan
Powered by blists - more mailing lists