[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1492169879.25766.4.camel@kernel.crashing.org>
Date: Fri, 14 Apr 2017 21:37:59 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Logan Gunthorpe <logang@...tatee.com>,
Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
Bjorn Helgaas <helgaas@...nel.org>
Cc: Christoph Hellwig <hch@....de>, Sagi Grimberg <sagi@...mberg.me>,
"James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Jens Axboe <axboe@...nel.dk>,
Steve Wise <swise@...ngridcomputing.com>,
Stephen Bates <sbates@...thlin.com>,
Max Gurtovoy <maxg@...lanox.com>,
Dan Williams <dan.j.williams@...el.com>,
Keith Busch <keith.busch@...el.com>, linux-pci@...r.kernel.org,
linux-scsi@...r.kernel.org, linux-nvme@...ts.infradead.org,
linux-rdma@...r.kernel.org, linux-nvdimm@...1.01.org,
linux-kernel@...r.kernel.org, Jerome Glisse <jglisse@...hat.com>
Subject: Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory
On Thu, 2017-04-13 at 22:40 -0600, Logan Gunthorpe wrote:
>
> On 13/04/17 10:16 PM, Jason Gunthorpe wrote:
> > I'd suggest just detecting if there is any translation in bus
> > addresses anywhere and just hard disabling P2P on such systems.
>
> That's a fantastic suggestion. It simplifies things significantly.
> Unless there are any significant objections I think I will plan on
> doing
> that.
I object.
> > On modern hardware with 64 bit BARs there is very little reason to
> > have translation, so I think this is a legacy feature.
>
> Yes, p2pmem users are likely to be designing systems around it (ie
> JBOFs) and not trying to shoehorn it onto legacy architectures.
>
> At the very least, it makes sense to leave it out and if someone
> comes
> along who cares they can put in the effort to support the address
> translation.
>
> Thanks,
>
> Logan
Powered by blists - more mailing lists