From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A1AB1C43613 for ; Mon, 24 Jun 2019 19:37:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7252620663 for ; Mon, 24 Jun 2019 19:37:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730539AbfFXTh0 (ORCPT ); Mon, 24 Jun 2019 15:37:26 -0400 Received: from ale.deltatee.com ([207.54.116.67]:41078 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729405AbfFXThZ (ORCPT ); Mon, 24 Jun 2019 15:37:25 -0400 Received: from guinness.priv.deltatee.com ([172.16.1.162]) by ale.deltatee.com with esmtp (Exim 4.89) (envelope-from ) id 1hfUm8-0002Af-EH; Mon, 24 Jun 2019 13:37:13 -0600 To: Jason Gunthorpe Cc: Christoph Hellwig , Dan Williams , Linux Kernel Mailing List , linux-block@vger.kernel.org, linux-nvme@lists.infradead.org, linux-pci@vger.kernel.org, linux-rdma , Jens Axboe , Bjorn Helgaas , Sagi Grimberg , Keith Busch , Stephen Bates References: <20190620161240.22738-1-logang@deltatee.com> <20190620193353.GF19891@ziepe.ca> <20190624073126.GB3954@lst.de> <20190624134641.GA8268@ziepe.ca> <20190624135024.GA11248@lst.de> <20190624135550.GB8268@ziepe.ca> <7210ba39-c923-79ca-57bb-7cf9afe21d54@deltatee.com> <20190624181632.GC8268@ziepe.ca> <20190624185444.GD8268@ziepe.ca> From: Logan Gunthorpe Message-ID: <980b6d6b-0232-51b6-5aae-03fa8e7fc8e5@deltatee.com> Date: Mon, 24 Jun 2019 13:37:10 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <20190624185444.GD8268@ziepe.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.162 X-SA-Exim-Rcpt-To: sbates@raithlin.com, kbusch@kernel.org, sagi@grimberg.me, bhelgaas@google.com, axboe@kernel.dk, linux-rdma@vger.kernel.org, linux-pci@vger.kernel.org, linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, dan.j.williams@intel.com, hch@lst.de, jgg@ziepe.ca X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: [RFC PATCH 00/28] Removing struct page from P2PDMA X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On 2019-06-24 12:54 p.m., Jason Gunthorpe wrote: > On Mon, Jun 24, 2019 at 12:28:33PM -0600, Logan Gunthorpe wrote: > >>> Sounded like this series does generate the dma_addr for the correct >>> device.. >> >> This series doesn't generate any DMA addresses with dma_map(). The >> current p2pdma code ensures everything is behind the same root port and >> only uses the pci bus address. This is valid and correct, but yes it's >> something to expand upon. > > I think if you do this it still has to be presented as the same API > like dma_map that takes in the target device * and produces the device > specific dma_addr_t Yes, once we consider the case where it can go through the root complex, we will need an API similar to dma_map(). We got rid of that API because it wasn't yet required or used by anything and, per our best practices, we don't add features that aren't used as that is more confusing for people reading/reworking the code. > Otherwise this whole thing is confusing and looks like *all* of it can > only work under the switch assumption Hopefully it'll be clearer once we do the work to map for going through the root complex. It's not that confusing to me. But it's all orthogonal to the dma_addr_t through the block layer concept. Logan