From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D36A741CFA; Tue, 21 Feb 2023 08:53:44 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C4D5B4318F; Tue, 21 Feb 2023 08:53:44 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id A38BC40E5A for ; Tue, 21 Feb 2023 08:53:43 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] net/hns3: support disable IOVA as PA mode Date: Tue, 21 Feb 2023 08:53:40 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87760@smartserver.smartshare.dk> In-Reply-To: <2007794.0S5aU1g85B@thomas> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] net/hns3: support disable IOVA as PA mode Thread-Index: AdlFQbZSNf+aaWVZSzql/APOY1WCjAAhKXWg References: <20230214071141.50155-1-fengchengwen@huawei.com> <24304924.kmuVQn2iE0@thomas> <2007794.0S5aU1g85B@thomas> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Thomas Monjalon" , "Bruce Richardson" Cc: "Chengwen Feng" , "Ruifeng Wang" , , "nd" , , "Dongdong Liu" , "Yisen Zhuang" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Monday, 20 February 2023 16.41 >=20 > 20/02/2023 16:35, Bruce Richardson: > > On Mon, Feb 20, 2023 at 04:30:20PM +0100, Thomas Monjalon wrote: > > > 20/02/2023 16:07, Morten Br=F8rup: > > > > With the new viewing angle, the current define RTE_IOVA_AS_PA > makes more sense to me now than before. So we should probably stick > with it, rather than introduce something that might confuse developers > who already have the same viewing angle. > > > > > > > > But it still seems counterintuitive to me that disabling some > feature ("enable_iova_as_pa") is not supported throughout DPDK; the > logic seems inverted. Apparently, it also makes it difficult to assign > good titles to patches that support disabling such a feature. :-) > > > > > > > > > > > > On the positive side, since everything supports this > "enable_iova_as_pa" feature, we don't need to add it to the PMD = feature > list. If the logic wasn't inverted like this, the PMD feature list > should probably reflect which PMDs supported the "iova_as_va_only" > compile time option. ;-) > > > > > > > > > > That's a change I would like to do: > > > The Meson variable in the drivers should be "support_iova_as_va" > > > and would mean we can compile the driver when "enable_iova_as_pa" > is false. > > > > > All drivers (that I am aware of) support iova_as_va. What is missing > is > > drivers supporting "iova_as_va_only". Any reference to va without = the > word > > "only" on it will be misleading. > > > > A third way of looking at it, is to work with the fact that the > reason > > drivers require changes to support this "va_only" mode, ro no-pa > mode, is > > due to the fact that the mbuf no longer tracks iovas and only VAs. > > Therefore, we can have a variable called "require_iova_in_mbuf", > which > > would hopefully cut through this whole va vs pa addition/subtraction > mess. > > What do you think? >=20 > Yes "require_iova_in_mbuf" describes better the reality, > so it is simpler to understand. Agreed. It is a good idea narrowing the scope to the concrete issue. Proceeding to also consider the source code using the corresponding = #define, e.g. the rte_mbuf: https://elixir.bootlin.com/dpdk/v23.03-rc1/source/lib/mbuf/rte_mbuf_core.= h#L469 Would you also change the corresponding #define from RTE_IOVA_AS_PA to = RTE_REQUIRE_IOVA_IN_MBUF? Perhaps we could invert the value, e.g. "mbuf_without_iova" and #define = RTE_MBUF_WITHOUT_IOVA? Intuitively, a default value of "false" better = reflects that the feature is optional. PS: I don't mind if you limit this to meson, and ignore my feature creep = expanding into #define land.