Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp2933779pxy; Mon, 3 May 2021 11:11:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyDc8cxsmXT+4kSkGoysVZF6MWwy7y/lQy2TQFOHdDDkQ+bRGQMFMLc6hAAUtsD3x5sQi5c X-Received: by 2002:a17:902:7205:b029:ed:6fc0:bbd4 with SMTP id ba5-20020a1709027205b02900ed6fc0bbd4mr22319938plb.4.1620065487652; Mon, 03 May 2021 11:11:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620065487; cv=none; d=google.com; s=arc-20160816; b=Rg+XsB8h2+E8xSLDDAztYp6itzigDqq5EchsEaNaz6BRmXGgc3i6qYZugUXxpQlLXM vYc/PdQzSLO962Bl/YaOJrpzOhnID8ZpS5OJO2tCsbMYIj8W8zxfEt/WT4hzNaHZeltT P7Tl9R481aKf/K/c5k8SKuWU55F5+JMQr90/TjN94va3TLOaFlaZifiXq+TS09+u9f9a AJ1Bw3f8JAJF3oWPWx6To819CS9xpcvhMwQJavg54woWT+Lw80u6LJlvGcgBfwFKN0J5 aBnTOtyvhDf5Oc/1+/7T9REbWbQ/Yn7jnevGvj8SrdyZ4EENppD0M2ZfQ7JrvYROrmdA bsvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:dkim-signature; bh=6WT0OUR3hjtTcavzEdie6Lc7Z9dy98V7OmbCellGUKQ=; b=rBZiBM1fpYx+ZvWDfG0Q9OSbDdMkcD/g70zPu94KdK554ZgPeJIRr6CyNZysWYReuN X8hhSt/ZR2ddnkcPqUAMajc07s6m6u3js0Fo0plFa+5ccI1C0H8Kr0Mcz6BN5+9/QdnP F6DdVWbX7UDTaVAlSjvedyYmUdCieOk+ZD998vXTXnNmR9HAqrT7Zxqp0grUCQfkz13k IozlrY/yjEwXrAU318BM9tXJmiO85yHRz1CO16XNISGB9ZLAwzIAEvr++WZqR8fZxAao XNog4eXHgC372cL1kqCzY14I5G4gNXcY7X5JJSHaIxIK4f24OYt/pSSXRz/jbVS4dNdD Oq5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@deltatee.com header.s=20200525 header.b=iSoi3m2K; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x4si453005pll.61.2021.05.03.11.11.15; Mon, 03 May 2021 11:11:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@deltatee.com header.s=20200525 header.b=iSoi3m2K; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231317AbhECQbc (ORCPT + 99 others); Mon, 3 May 2021 12:31:32 -0400 Received: from ale.deltatee.com ([204.191.154.188]:57246 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231305AbhECQba (ORCPT ); Mon, 3 May 2021 12:31:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=deltatee.com; s=20200525; h=Subject:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:content-disposition; bh=6WT0OUR3hjtTcavzEdie6Lc7Z9dy98V7OmbCellGUKQ=; b=iSoi3m2KmtK1HP7gIRg1noBzhL NtSADOj0t1i5+64Ao6MTgqBy53Oi5hySB1oaSupB48LrYAe6WSHgX3sRePeOmRSBeOalLwq3PjLPe o7VWjNhWg9bzTER3go24x5rY4NvcXrNHSG27dPCq8FaviCpfTy6oAmfGHttkYx1zLPVHclNk+ZT3v hOI/J3t/5Sqbz+qntMkChEOhBBbxyjMtkPXUOkK/z1Y3q/JFHcnBDRIwMPc/9kvijxshC5QTCuOyS SxxEAdJQLddlRqnk0FBt+k4stxyPW+VkbiUafpJFRXjJC94bHUQiCofxZEm+6s4anxL6tsme1AtkS LKE4otqA==; Received: from guinness.priv.deltatee.com ([172.16.1.162]) by ale.deltatee.com with esmtp (Exim 4.92) (envelope-from ) id 1ldbSh-00043Q-48; Mon, 03 May 2021 10:30:24 -0600 To: John Hubbard , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, iommu@lists.linux-foundation.org Cc: Stephen Bates , Christoph Hellwig , Dan Williams , Jason Gunthorpe , =?UTF-8?Q?Christian_K=c3=b6nig?= , Don Dutile , Matthew Wilcox , Daniel Vetter , Jakowski Andrzej , Minturn Dave B , Jason Ekstrand , Dave Hansen , Xiong Jianxin , Bjorn Helgaas , Ira Weiny , Robin Murphy References: <20210408170123.8788-1-logang@deltatee.com> <20210408170123.8788-5-logang@deltatee.com> From: Logan Gunthorpe Message-ID: Date: Mon, 3 May 2021 10:30:21 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: 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: robin.murphy@arm.com, ira.weiny@intel.com, helgaas@kernel.org, jianxin.xiong@intel.com, dave.hansen@linux.intel.com, jason@jlekstrand.net, dave.b.minturn@intel.com, andrzej.jakowski@intel.com, daniel.vetter@ffwll.ch, willy@infradead.org, ddutile@redhat.com, christian.koenig@amd.com, jgg@ziepe.ca, dan.j.williams@intel.com, hch@lst.de, sbates@raithlin.com, iommu@lists.linux-foundation.org, linux-mm@kvack.org, linux-pci@vger.kernel.org, linux-block@vger.kernel.org, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org, jhubbard@nvidia.com X-SA-Exim-Mail-From: logang@deltatee.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on ale.deltatee.com X-Spam-Level: X-Spam-Status: No, score=-8.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, GREYLIST_ISWHITE,NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.2 Subject: Re: [PATCH 04/16] PCI/P2PDMA: Refactor pci_p2pdma_map_type() to take pagmap and device X-SA-Exim-Version: 4.2.1 (built Wed, 08 May 2019 21:11:16 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-05-02 2:41 p.m., John Hubbard wrote: > On 4/8/21 10:01 AM, Logan Gunthorpe wrote: >> All callers of pci_p2pdma_map_type() have a struct dev_pgmap and a >> struct device (of the client doing the DMA transfer). Thus move the >> conversion to struct pci_devs for the provider and client into this >> function. > > Actually, this is the wrong direction to go! All of these pre-existing > pci_*() functions have a small problem already: they are dealing with > struct device, instead of struct pci_dev. And so refactoring should be > pushing the conversion to pci_dev *up* the calling stack, not lower as > the patch here proposes. > > Also, there is no improvement in clarity by passing in (pgmap, dev) > instead of the previous (provider, client). Now you have to do more type > checking in the leaf function, which is another indication of a problem. > > Let's go that direction, please? Just convert to pci_dev much higher in > the calling stack, and you'll find that everything fits together better. > And it's OK to pass in extra params if that turns out to be necessary, > after all. No, I disagree with this and it seems a bit confused. This change is allowing callers to call the function with what they have and doing more checks inside the called function. This allows for *less* checks in the leaf function, not more checks. (I mean, look at the patch itself, it puts a bunch of checks in both call sites into the callee and makes the code a lot cleaner -- it's removing more lines than it adds). Similar argument can be made with the pci_p2pdma_distance_many() (which I assume you are referring to). If the function took struct pci_dev instead of struct device, every caller would need to do all checks and conversions to struct pci_dev. That is not an improvement. Logan