From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 8BAB441E1D;
Mon, 13 Mar 2023 16:51:38 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 7CF4E410D1;
Mon, 13 Mar 2023 16:51:38 +0100 (CET)
Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com
[66.111.4.230]) by mails.dpdk.org (Postfix) with ESMTP id 435F140E03
for <dev@dpdk.org>; Mon, 13 Mar 2023 16:51:37 +0100 (CET)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
by mailnew.nyi.internal (Postfix) with ESMTP id 8B408581FCC;
Mon, 13 Mar 2023 11:51:35 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
by compute4.internal (MEProxy); Mon, 13 Mar 2023 11:51:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
cc:cc:content-transfer-encoding:content-type:content-type:date
:date:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:sender:subject:subject:to:to; s=fm2; t=
1678722695; x=1678729895; bh=2aCPU9V6Yfo1ebZW1/1AEOxUiHyv9UhpWiM
ZvEMXYWk=; b=cKKMpEaqjd82rYMYZlEqUHera93aZdu7pOa6Ge8F2HLBJr5xFIC
xQ3EEn35UiwzPLcGvTLQj6U5IYwrKwo5nO+bUba4c5nShwV92q8aQTGU1srTn3HZ
DgQsmhVgBaHT7+slXOfWc/VImoxtnb3cGO/gEvx/G2b7VqrUVrWUdPXFPfoIMmO9
3UobvwbkADlzaHbGKGKPXPFXHZHVnHVNRzsscTPawoDW75iDoEPeMA9WDrlrIWsF
UPHN5il8hN+retX3Wn2vOypziJu1G/HyAYW9zsHrY9xaRCKxBLc35p7/BE6CVNIk
u4XULSiRl1u7C5lFsnm/4hWv8MOuSFOiyEA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-transfer-encoding
:content-type:content-type:date:date:feedback-id:feedback-id
:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:sender:subject:subject:to:to:x-me-proxy
:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=
1678722695; x=1678729895; bh=2aCPU9V6Yfo1ebZW1/1AEOxUiHyv9UhpWiM
ZvEMXYWk=; b=YSrIIQfEVrxBkqUV60wz1nj7L4A9NFQNg+dXLSNj7aBInFgrn39
jqGS3XPoTNhNR/s3BUVfjb0qxcJViPO6q6FYz0naU2LpRzEUlVi0EmVwMix0vpoY
Zu7ge0uXXj6i9RYejVzoOK/h/tMydn+YaQ9accJJB7jEt8zjZMzaQi0DwNje5DYf
S2MPk6H1Xyndf22uScBBEVyWN/rWmzxPeYl6uArk9TVdci1jO3F/K4tMyc7gInQo
w+dEpeggFcrPfwAIrDk8pj9kAkjFDQ21lUDSxq+uSuDyzTZBOlczetSrDvUSM2BX
Sl++jN9sGHEFGUgvuJOx9XMbUcQ9WlM1PQw==
X-ME-Sender: <xms:hkYPZFmqhim6DZyqE5dskaZWN7b6YTSydsnQtApaLaHE9sbDwCqucw>
<xme:hkYPZA2aZCsBBxmoMhN87SCPiJoetIqbb5EMhxvYSkDPg8Ciqyx3vK6ePTI5D9p6r
0Kom_I0Exvs-NXfSQ>
X-ME-Received: <xmr:hkYPZLqdmR2D879yBUuKxmOD_RNS4WRUIKUSZCCuf7TJytL_ewECkUdOAG63JCnmbROGpSGMUcvvG90T92blDPGpXg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvddvgedgkedtucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm
rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc
ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei
kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh
hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght
X-ME-Proxy: <xmx:hkYPZFmweJZqKcSADJ6LzaOhQfI45WHBkfN4JXuGSC8Z5obe1KgSRQ>
<xmx:hkYPZD3QInx9YvGPDaobDQhLluKWvbXK-WIcjIo9bAayqsY-Jc5h8w>
<xmx:hkYPZEsUDIGZBuCtf_zJInpajsklTZ_FmkldyhIGtIM3LkFfCLO_wQ>
<xmx:h0YPZJGngOovOEE8fho3JTiGQxnRTnLKOYDJGfmpDTw85cmHzT58iw>
Feedback-ID: i47234305:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
13 Mar 2023 11:51:30 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: fengchengwen <fengchengwen@huawei.com>,
Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org, dev@dpdk.org, David Marchand <david.marchand@redhat.com>,
Qi Zhang <qi.z.zhang@intel.com>,
Morten =?ISO-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com>,
Shijith Thotton <sthotton@marvell.com>,
Olivier Matz <olivier.matz@6wind.com>, Ruifeng Wang <ruifeng.wang@arm.com>,
Nithin Dabilpuram <ndabilpuram@marvell.com>,
Kiran Kumar K <kirankumark@marvell.com>,
Sunil Kumar Kori <skori@marvell.com>, Satha Rao <skoteshwar@marvell.com>,
Jingjing Wu <jingjing.wu@intel.com>, Beilei Xing <beilei.xing@intel.com>,
Ankur Dwivedi <adwivedi@marvell.com>, Anoob Joseph <anoobj@marvell.com>,
Tejasree Kondoj <ktejasree@marvell.com>, Kai Ji <kai.ji@intel.com>,
Pablo de Lara <pablo.de.lara.guarch@intel.com>,
Radha Mohan Chintakuntla <radhac@marvell.com>,
Veerasenareddy Burru <vburru@marvell.com>,
Kevin Laatz <kevin.laatz@intel.com>,
Pavan Nikhilesh <pbhagavatula@marvell.com>,
Mattias =?ISO-8859-1?Q?R=F6nnblom?= <mattias.ronnblom@ericsson.com>,
Liang Ma <liangma@liangbit.com>, Peter Mccarthy <peter.mccarthy@intel.com>,
Jerin Jacob <jerinj@marvell.com>,
Harry van Haaren <harry.van.haaren@intel.com>,
"Artem V. Andreev" <artem.andreev@oktetlabs.ru>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Ashwin Sekhar T K <asekhar@marvell.com>,
"John W. Linville" <linville@tuxdriver.com>,
Ciara Loftus <ciara.loftus@intel.com>, Chas Williams <chas3@att.com>,
"Min Hu (Connor)" <humin29@huawei.com>, Gaetan Rivet <grive@u256.net>,
Dongdong Liu <liudongdong3@huawei.com>,
Yisen Zhuang <yisen.zhuang@huawei.com>,
Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>,
Qiming Yang <qiming.yang@intel.com>, Jakub Grajciar <jgrajcia@cisco.com>,
Tetsuya Mukawa <mtetsuyah@gmail.com>, Jakub Palider <jpalider@marvell.com>,
Tomasz Duszynski <tduszynski@marvell.com>,
Sachin Saxena <sachin.saxena@nxp.com>,
Hemant Agrawal <hemant.agrawal@nxp.com>
Subject: Re: [PATCH v2 1/2] build: clarify configuration without IOVA field in
mbuf
Date: Mon, 13 Mar 2023 16:51:27 +0100
Message-ID: <10902328.BaYr0rKQ5T@thomas>
In-Reply-To: <ZAnatGYDiPYsiiyg@bricha3-MOBL.ger.corp.intel.com>
References: <20230219115529.3260580-1-thomas@monjalon.net>
<4250554.ejJDZkT8p0@thomas>
<ZAnatGYDiPYsiiyg@bricha3-MOBL.ger.corp.intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
09/03/2023 14:10, Bruce Richardson:
> On Thu, Mar 09, 2023 at 01:12:51PM +0100, Thomas Monjalon wrote:
> > 09/03/2023 12:23, fengchengwen:
> > > On 2023/3/9 15:29, Thomas Monjalon wrote:
> > > > 09/03/2023 02:43, fengchengwen:
> > > >> On 2023/3/7 0:13, Thomas Monjalon wrote:
> > > >>> --- a/doc/guides/rel_notes/release_22_11.rst
> > > >>> +++ b/doc/guides/rel_notes/release_22_11.rst
> > > >>> @@ -504,7 +504,7 @@ ABI Changes
> > > >>> ``rte-worker-<lcore_id>`` so that DPDK can accommodate lcores higher than 99.
> > > >>>
> > > >>> * mbuf: Replaced ``buf_iova`` field with ``next`` field and added a new field
> > > >>> - ``dynfield2`` at its place in second cacheline if ``RTE_IOVA_AS_PA`` is 0.
> > > >>> + ``dynfield2`` at its place in second cacheline if ``RTE_IOVA_IN_MBUF`` is 0.
> > > >>
> > > >> Should add to release 23.03 rst.
> > > >
> > > > Yes we could add a note in API changes.
> > > >
> > > >> The original 22.11 still have RTE_IOVA_AS_PA definition.
> > > >
> > > > Yes it was not a good idea to rename in the release notes.
> > > >
> > > >>> -if dpdk_conf.get('RTE_IOVA_AS_PA') == 0
> > > >>> - build = false
> > > >>> - reason = 'driver does not support disabling IOVA as PA mode'
> > > >>> +if not get_option('enable_iova_as_pa')
> > > >>> subdir_done()
> > > >>> endif
> > > >>
> > > >> Suggest keep original, and replace RTE_IOVA_AS_PA with RTE_IOVA_IN_MBUF:
> > > >> if dpdk_conf.get('RTE_IOVA_IN_MBUF') == 0
> > > >> subdir_done()
> > > >> endif
> > > >
> > > > Why testing the C macro in Meson?
> > > > It looks simpler to check the Meson option in Meson.
> > >
> > > The macro was create in meson.build: config/meson.build:319:dpdk_conf.set10('RTE_IOVA_AS_PA', get_option('enable_iova_as_pa'))
> > > It can be regarded as alias of enable_iova_as_pa.
> >
> > It is not strictly an alias, because it can be overriden via CFLAGS.
> >
> > > This commit was mainly used to improve comprehensibility. so we should limit the 'enable_iova_as_pa' usage scope.
> > > and the 'if dpdk_conf.get('RTE_IOVA_IN_MBUF') == 0' is more comprehensibility than 'if not get_option('enable_iova_as_pa')'
> >
> > To me, using Meson option in Meson files is more obvious.
> >
> > Bruce, what do you think?
> >
>
> I'm not sure it matters much! However, I think of the two, using the
> reference to IOVA_IN_MBUF is clearer. It also allows the same terminology
> to be used in meson and C files. If we don't want to do a dpdk_conf lookup,
> we can always assign the option to a meson variable called iova_in_mbuf.
OK I'll query the C macro in the Meson files.