From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ale.deltatee.com (ale.deltatee.com [207.54.116.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E6FD32193930D for ; Mon, 3 Apr 2017 15:10:34 -0700 (PDT) References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1490911959-5146-6-git-send-email-logang@deltatee.com> <20170331070950.GA9059@infradead.org> <435d4471-436b-87e6-8827-c9fc6cbdde2c@deltatee.com> <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> From: Logan Gunthorpe Message-ID: Date: Mon, 3 Apr 2017 16:10:27 -0600 MIME-Version: 1.0 In-Reply-To: Subject: Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Jens Axboe , Keith Busch , "James E.J. Bottomley" , linux-scsi , "Martin K. Petersen" , "linux-nvdimm@lists.01.org" , linux-rdma@vger.kernel.org, linux-pci@vger.kernel.org, Steve Wise , "linux-kernel@vger.kernel.org" , linux-nvme@lists.infradead.org, Christoph Hellwig , Max Gurtovoy , Christoph Hellwig , Jason Gunthorpe List-ID: On 03/04/17 03:44 PM, Dan Williams wrote: > On Mon, Apr 3, 2017 at 2:20 PM, Logan Gunthorpe wrote: >> Hi Christoph, >> >> What are your thoughts on an approach like the following untested >> draft patch. >> >> The patch (if fleshed out) makes it so iomem can be used in an sgl >> and WARN_ONs will occur in places where drivers attempt to access >> iomem directly through the sgl. >> >> I'd also probably create a p2pmem_alloc_sgl helper function so driver >> writers wouldn't have to mess with sg_set_iomem_page. >> >> With all that in place, it should be relatively safe for drivers to >> implement p2pmem even though we'd still technically be violating the >> __iomem boundary in some places. > > Just reacting to this mail, I still haven't had a chance to take a > look at the rest of the series. > > The pfn_t type was invented to carry extra type and page lookup > information about the memory behind a given pfn. At first glance that > seems a more natural place to carry an indication that this is an > "I/O" pfn. I agree... But what are the plans for pfn_t? Is anyone working on using it in the scatterlist code? Currently it's not there yet and given the assertion that we will continue to be using struct page for DMA is that a direction we'd want to go? Logan _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 From: Logan Gunthorpe Subject: Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory. Date: Mon, 3 Apr 2017 16:10:27 -0600 Message-ID: References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1490911959-5146-6-git-send-email-logang@deltatee.com> <20170331070950.GA9059@infradead.org> <435d4471-436b-87e6-8827-c9fc6cbdde2c@deltatee.com> <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Jens Axboe , Keith Busch , "James E.J. Bottomley" , linux-scsi , "Martin K. Petersen" , "linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org" , 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, Christoph Hellwig , Max Gurtovoy , Christoph Hellwig , Jason Gunthorpe List-Id: linux-rdma@vger.kernel.org On 03/04/17 03:44 PM, Dan Williams wrote: > On Mon, Apr 3, 2017 at 2:20 PM, Logan Gunthorpe wrote: >> Hi Christoph, >> >> What are your thoughts on an approach like the following untested >> draft patch. >> >> The patch (if fleshed out) makes it so iomem can be used in an sgl >> and WARN_ONs will occur in places where drivers attempt to access >> iomem directly through the sgl. >> >> I'd also probably create a p2pmem_alloc_sgl helper function so driver >> writers wouldn't have to mess with sg_set_iomem_page. >> >> With all that in place, it should be relatively safe for drivers to >> implement p2pmem even though we'd still technically be violating the >> __iomem boundary in some places. > > Just reacting to this mail, I still haven't had a chance to take a > look at the rest of the series. > > The pfn_t type was invented to carry extra type and page lookup > information about the memory behind a given pfn. At first glance that > seems a more natural place to carry an indication that this is an > "I/O" pfn. I agree... But what are the plans for pfn_t? Is anyone working on using it in the scatterlist code? Currently it's not there yet and given the assertion that we will continue to be using struct page for DMA is that a direction we'd want to go? Logan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752169AbdDCWKn (ORCPT ); Mon, 3 Apr 2017 18:10:43 -0400 Received: from ale.deltatee.com ([207.54.116.67]:57079 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751932AbdDCWKk (ORCPT ); Mon, 3 Apr 2017 18:10:40 -0400 To: Dan Williams References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1490911959-5146-6-git-send-email-logang@deltatee.com> <20170331070950.GA9059@infradead.org> <435d4471-436b-87e6-8827-c9fc6cbdde2c@deltatee.com> <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> Cc: Christoph Hellwig , Jens Axboe , Keith Busch , "James E.J. Bottomley" , linux-scsi , "Martin K. Petersen" , "linux-nvdimm@lists.01.org" , linux-rdma@vger.kernel.org, linux-pci@vger.kernel.org, Steve Wise , "linux-kernel@vger.kernel.org" , linux-nvme@lists.infradead.org, Jason Gunthorpe , Max Gurtovoy , Christoph Hellwig From: Logan Gunthorpe Message-ID: Date: Mon, 3 Apr 2017 16:10:27 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.111 X-SA-Exim-Rcpt-To: hch@lst.de, maxg@mellanox.com, jgunthorpe@obsidianresearch.com, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, swise@opengridcomputing.com, linux-pci@vger.kernel.org, linux-rdma@vger.kernel.org, linux-nvdimm@lists.01.org, martin.petersen@oracle.com, linux-scsi@vger.kernel.org, jejb@linux.vnet.ibm.com, keith.busch@intel.com, axboe@kernel.dk, hch@infradead.org, dan.j.williams@intel.com X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory. X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/04/17 03:44 PM, Dan Williams wrote: > On Mon, Apr 3, 2017 at 2:20 PM, Logan Gunthorpe wrote: >> Hi Christoph, >> >> What are your thoughts on an approach like the following untested >> draft patch. >> >> The patch (if fleshed out) makes it so iomem can be used in an sgl >> and WARN_ONs will occur in places where drivers attempt to access >> iomem directly through the sgl. >> >> I'd also probably create a p2pmem_alloc_sgl helper function so driver >> writers wouldn't have to mess with sg_set_iomem_page. >> >> With all that in place, it should be relatively safe for drivers to >> implement p2pmem even though we'd still technically be violating the >> __iomem boundary in some places. > > Just reacting to this mail, I still haven't had a chance to take a > look at the rest of the series. > > The pfn_t type was invented to carry extra type and page lookup > information about the memory behind a given pfn. At first glance that > seems a more natural place to carry an indication that this is an > "I/O" pfn. I agree... But what are the plans for pfn_t? Is anyone working on using it in the scatterlist code? Currently it's not there yet and given the assertion that we will continue to be using struct page for DMA is that a direction we'd want to go? Logan From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ale.deltatee.com ([207.54.116.67]:57079 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751932AbdDCWKk (ORCPT ); Mon, 3 Apr 2017 18:10:40 -0400 To: Dan Williams References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1490911959-5146-6-git-send-email-logang@deltatee.com> <20170331070950.GA9059@infradead.org> <435d4471-436b-87e6-8827-c9fc6cbdde2c@deltatee.com> <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> Cc: Christoph Hellwig , Jens Axboe , Keith Busch , "James E.J. Bottomley" , linux-scsi , "Martin K. Petersen" , "linux-nvdimm@lists.01.org" , linux-rdma@vger.kernel.org, linux-pci@vger.kernel.org, Steve Wise , "linux-kernel@vger.kernel.org" , linux-nvme@lists.infradead.org, Jason Gunthorpe , Max Gurtovoy , Christoph Hellwig From: Logan Gunthorpe Message-ID: Date: Mon, 3 Apr 2017 16:10:27 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Subject: Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory. Sender: linux-pci-owner@vger.kernel.org List-ID: On 03/04/17 03:44 PM, Dan Williams wrote: > On Mon, Apr 3, 2017 at 2:20 PM, Logan Gunthorpe wrote: >> Hi Christoph, >> >> What are your thoughts on an approach like the following untested >> draft patch. >> >> The patch (if fleshed out) makes it so iomem can be used in an sgl >> and WARN_ONs will occur in places where drivers attempt to access >> iomem directly through the sgl. >> >> I'd also probably create a p2pmem_alloc_sgl helper function so driver >> writers wouldn't have to mess with sg_set_iomem_page. >> >> With all that in place, it should be relatively safe for drivers to >> implement p2pmem even though we'd still technically be violating the >> __iomem boundary in some places. > > Just reacting to this mail, I still haven't had a chance to take a > look at the rest of the series. > > The pfn_t type was invented to carry extra type and page lookup > information about the memory behind a given pfn. At first glance that > seems a more natural place to carry an indication that this is an > "I/O" pfn. I agree... But what are the plans for pfn_t? Is anyone working on using it in the scatterlist code? Currently it's not there yet and given the assertion that we will continue to be using struct page for DMA is that a direction we'd want to go? Logan From mboxrd@z Thu Jan 1 00:00:00 1970 From: logang@deltatee.com (Logan Gunthorpe) Date: Mon, 3 Apr 2017 16:10:27 -0600 Subject: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory. In-Reply-To: References: <1490911959-5146-1-git-send-email-logang@deltatee.com> <1490911959-5146-6-git-send-email-logang@deltatee.com> <20170331070950.GA9059@infradead.org> <435d4471-436b-87e6-8827-c9fc6cbdde2c@deltatee.com> <445bc352-75d7-438f-96ef-c2411215628d@deltatee.com> Message-ID: On 03/04/17 03:44 PM, Dan Williams wrote: > On Mon, Apr 3, 2017@2:20 PM, Logan Gunthorpe wrote: >> Hi Christoph, >> >> What are your thoughts on an approach like the following untested >> draft patch. >> >> The patch (if fleshed out) makes it so iomem can be used in an sgl >> and WARN_ONs will occur in places where drivers attempt to access >> iomem directly through the sgl. >> >> I'd also probably create a p2pmem_alloc_sgl helper function so driver >> writers wouldn't have to mess with sg_set_iomem_page. >> >> With all that in place, it should be relatively safe for drivers to >> implement p2pmem even though we'd still technically be violating the >> __iomem boundary in some places. > > Just reacting to this mail, I still haven't had a chance to take a > look at the rest of the series. > > The pfn_t type was invented to carry extra type and page lookup > information about the memory behind a given pfn. At first glance that > seems a more natural place to carry an indication that this is an > "I/O" pfn. I agree... But what are the plans for pfn_t? Is anyone working on using it in the scatterlist code? Currently it's not there yet and given the assertion that we will continue to be using struct page for DMA is that a direction we'd want to go? Logan