From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory Date: Mon, 17 Apr 2017 08:32:38 +1000 Message-ID: <1492381958.25766.50.camel@kernel.crashing.org> References: <6e732d6a-9baf-1768-3e9c-f6c887a836b2@deltatee.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <6e732d6a-9baf-1768-3e9c-f6c887a836b2-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: Logan Gunthorpe , Dan Williams Cc: Jens Axboe , Keith Busch , "James E.J. Bottomley" , "Martin K. Petersen" , linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Steve Wise , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Jason Gunthorpe , Jerome Glisse , Bjorn Helgaas , linux-scsi , linux-nvdimm , Max Gurtovoy , Christoph Hellwig List-Id: linux-nvdimm@lists.01.org On Sun, 2017-04-16 at 10:47 -0600, Logan Gunthorpe wrote: > > I think you need to give other archs a chance to support this with a > > design that considers the offset case as a first class citizen rather > > than an afterthought. > > I'll consider this. Given the fact I can use your existing > get_dev_pagemap infrastructure to look up the p2pmem device this > probably isn't as hard as I thought it would be anyway (we probably > don't even need a page flag). We'd just have lookup the dev_pagemap, > test if it's a p2pmem device, and if so, call a p2pmem_dma_map function > which could apply the offset or do any other arch specific logic (if > necessary). I'm still not 100% why do you need a "p2mem device" mind you ... Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 From: benh@kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 17 Apr 2017 08:32:38 +1000 Subject: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory In-Reply-To: <6e732d6a-9baf-1768-3e9c-f6c887a836b2@deltatee.com> References: <6e732d6a-9baf-1768-3e9c-f6c887a836b2@deltatee.com> Message-ID: <1492381958.25766.50.camel@kernel.crashing.org> On Sun, 2017-04-16@10:47 -0600, Logan Gunthorpe wrote: > > I think you need to give other archs a chance to support this with a > > design that considers the offset case as a first class citizen rather > > than an afterthought. > > I'll consider this. Given the fact I can use your existing > get_dev_pagemap infrastructure to look up the p2pmem device this > probably isn't as hard as I thought it would be anyway (we probably > don't even need a page flag). We'd just have lookup the dev_pagemap, > test if it's a p2pmem device, and if so, call a p2pmem_dma_map function > which could apply the offset or do any other arch specific logic (if > necessary). I'm still not 100% why do you need a "p2mem device" mind you ... Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Message-ID: <1492381958.25766.50.camel@kernel.crashing.org> Subject: Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory From: Benjamin Herrenschmidt To: Logan Gunthorpe , Dan Williams Cc: Bjorn Helgaas , Jason Gunthorpe , 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 Date: Mon, 17 Apr 2017 08:32:38 +1000 In-Reply-To: <6e732d6a-9baf-1768-3e9c-f6c887a836b2@deltatee.com> References: <6e732d6a-9baf-1768-3e9c-f6c887a836b2@deltatee.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 List-ID: On Sun, 2017-04-16 at 10:47 -0600, Logan Gunthorpe wrote: > > I think you need to give other archs a chance to support this with a > > design that considers the offset case as a first class citizen rather > > than an afterthought. > > I'll consider this. Given the fact I can use your existing > get_dev_pagemap infrastructure to look up the p2pmem device this > probably isn't as hard as I thought it would be anyway (we probably > don't even need a page flag). We'd just have lookup the dev_pagemap, > test if it's a p2pmem device, and if so, call a p2pmem_dma_map function > which could apply the offset or do any other arch specific logic (if > necessary). I'm still not 100% why do you need a "p2mem device" mind you ... Cheers, Ben.