From patchwork Tue Apr 18 21:03:39 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Gunthorpe X-Patchwork-Id: 9686301 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 739BC601C2 for ; Tue, 18 Apr 2017 21:04:20 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 65DAC2838E for ; Tue, 18 Apr 2017 21:04:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5A606283F2; Tue, 18 Apr 2017 21:04:20 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F3DDD2838E for ; Tue, 18 Apr 2017 21:04:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752310AbdDRVES (ORCPT ); Tue, 18 Apr 2017 17:04:18 -0400 Received: from quartz.orcorp.ca ([184.70.90.242]:46016 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752148AbdDRVER (ORCPT ); Tue, 18 Apr 2017 17:04:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=obsidianresearch.com; s=rsa1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=k8rznlqw4Fq6J1Dy0ej25tjdkU1gTIKS2UKyMGLPmIo=; b=ZS3XkuBCTWEm7spzKUsSstmftcORKxTjUJQan7UGNMeAH8gT5CT/jgV7vSpHPD+4TPgZxBNyeiBaFhK0EQjycWNpz9+h0djSjYN/r0i5cJtGkER8PDPYDljkQ2S7AMp7/GTi9JW7gAWklndxuiHxC0mymPBKWbn4EfHWgv/fPqE=; Received: from [10.0.0.156] (helo=jggl.edm.orcorp.ca) by quartz.orcorp.ca with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1d0aHk-0007UY-4O; Tue, 18 Apr 2017 15:03:40 -0600 Received: from jgg by jggl.edm.orcorp.ca with local (Exim 4.86_2) (envelope-from ) id 1d0aHk-0006yF-15; Tue, 18 Apr 2017 15:03:40 -0600 Date: Tue, 18 Apr 2017 15:03:39 -0600 From: Jason Gunthorpe To: Dan Williams Cc: Logan Gunthorpe , Benjamin Herrenschmidt , Bjorn Helgaas , 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 Subject: Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory Message-ID: <20170418210339.GA24257@obsidianresearch.com> References: <1492381396.25766.43.camel@kernel.crashing.org> <20170418164557.GA7181@obsidianresearch.com> <20170418190138.GH7181@obsidianresearch.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.156 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Apr 18, 2017 at 12:48:35PM -0700, Dan Williams wrote: > > Yes, I noticed this problem too and that makes sense. It just means > > every dma_ops will probably need to be modified to either support p2p > > pages or fail on them. Though, the only real difficulty there is that it > > will be a lot of work. > > I don't think you need to go touch all dma_ops, I think you can just > arrange for devices that are going to do dma to get redirected to a > p2p aware provider of operations that overrides the system default > dma_ops. I.e. just touch get_dma_ops(). I don't follow, when does get_dma_ops() return a p2p aware provider? It has no way to know if the DMA is going to involve p2p, get_dma_ops is called with the device initiating the DMA. So you'd always return the P2P shim on a system that has registered P2P memory? Even so, how does this shim work? dma_ops are not really intended to be stacked. How would we make unmap work, for instance? What happens when the underlying iommu dma ops actually natively understands p2p and doesn't want the shim? I think this opens an even bigger can of worms.. Lets find a strategy to safely push this into dma_ops. What about something more incremental like this instead: - dma_ops will set map_sg_p2p == map_sg when they are updated to support p2p, otherwise DMA on P2P pages will fail for those ops. - When all ops support p2p we remove the if and ops->map_sg then just call map_sg_p2p - For now the scatterlist maintains a bit when pages are added indicating if p2p memory might be present in the list. - Unmap for p2p and non-p2p is the same, the underlying ops driver has to make it work. diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h index 0977317c6835c2..505ed7d502053d 100644 --- a/include/linux/dma-mapping.h +++ b/include/linux/dma-mapping.h @@ -103,6 +103,9 @@ struct dma_map_ops { int (*map_sg)(struct device *dev, struct scatterlist *sg, int nents, enum dma_data_direction dir, unsigned long attrs); + int (*map_sg_p2p)(struct device *dev, struct scatterlist *sg, + int nents, enum dma_data_direction dir, + unsigned long attrs); void (*unmap_sg)(struct device *dev, struct scatterlist *sg, int nents, enum dma_data_direction dir, @@ -244,7 +247,15 @@ static inline int dma_map_sg_attrs(struct device *dev, struct scatterlist *sg, for_each_sg(sg, s, nents, i) kmemcheck_mark_initialized(sg_virt(s), s->length); BUG_ON(!valid_dma_direction(dir)); - ents = ops->map_sg(dev, sg, nents, dir, attrs); + + if (sg_has_p2p(sg)) { + if (ops->map_sg_p2p) + ents = ops->map_sg_p2p(dev, sg, nents, dir, attrs); + else + return 0; + } else + ents = ops->map_sg(dev, sg, nents, dir, attrs); + BUG_ON(ents < 0); debug_dma_map_sg(dev, sg, nents, ents, dir);