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 BC88C41E25; Thu, 9 Mar 2023 13:13:08 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A668340FAE; Thu, 9 Mar 2023 13:13:08 +0100 (CET) Received: from wnew2-smtp.messagingengine.com (wnew2-smtp.messagingengine.com [64.147.123.27]) by mails.dpdk.org (Postfix) with ESMTP id F078F400D7 for ; Thu, 9 Mar 2023 13:13:06 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.west.internal (Postfix) with ESMTP id 763682B06686; Thu, 9 Mar 2023 07:13:00 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 09 Mar 2023 07:13:03 -0500 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=fm1; t= 1678363980; x=1678371180; bh=wxcCZVxyZIB9SNsU15D4Cv/PfjmMTm5Q18e NsTkkuEw=; b=BYuZ3PB4VEJHNkWNvPqf1F8PHGB+qVCv0x/V2V2cxNDo6mDieyE qPdGOrtpWffeJ2DcBN59w/ttZ8tc2yukZoHXlKlmED3Ty6vHO/VwnBkWn+duvZiE 4CbSZTeE6ah1J4vJeDSwbsZmhOxwcPcG1lBoFG6YMp0OXUUzT+K8bP5mGHbMl1R6 WORThkRzq7nzNUxLy9KUsGNA2Q9Wsmr7FJwT/cnybn8H5w+5w6YZX09lqnKsdp0N 7wwSOi6YB84Brc763wMmqROcxsaOHUfJrlV4Ad2GGMQiuNiLpBXAUNhb7W2zsMzD 31mbPCKCAxbKndPtY592ID+fRM0HPIyaoWQ== 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=fm1; t= 1678363980; x=1678371180; bh=wxcCZVxyZIB9SNsU15D4Cv/PfjmMTm5Q18e NsTkkuEw=; b=VDG3Rww1yifv+ZP8XDZq4pA4QqoQvEokW/70TooN9Zyz3qb+L0/ hzcif5wrSv0nmWn8phGUiQHmR9Tx05+wXQkijQobL5F3nynnR7TCHxghp6/lbm61 w6yJqPpZB5jVngRRUkOvQ2yIFA9unVZ0/hXGEMANXlCY1kvPbz9w+uu0QLcnUAwj 00Y+pbNJAomCwNT632om3Bh6awDFNPfROE6hdIdYoIafG1ZNqJfS3NHCg2KNqgms LFoSLkoKC1nZs4cnSICsbWTcQLGrB8zMJSonoJQ6sHGBrEHuDrb7gFaMU2hh21aD focIyNkBiUM+hcEkBFeVyIhNsq8YHOUxoZw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdduiedgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 9 Mar 2023 07:12:52 -0500 (EST) From: Thomas Monjalon To: Bruce Richardson , fengchengwen Cc: dev@dpdk.org, David Marchand , Qi Zhang , Morten =?ISO-8859-1?Q?Br=F8rup?= , Shijith Thotton , Olivier Matz , Ruifeng Wang , Nithin Dabilpuram , Kiran Kumar K , Sunil Kumar Kori , Satha Rao , Jingjing Wu , Beilei Xing , Ankur Dwivedi , Anoob Joseph , Tejasree Kondoj , Kai Ji , Pablo de Lara , Radha Mohan Chintakuntla , Veerasenareddy Burru , Kevin Laatz , Pavan Nikhilesh , Mattias =?ISO-8859-1?Q?R=F6nnblom?= , Liang Ma , Peter Mccarthy , Jerin Jacob , Harry van Haaren , "Artem V. Andreev" , Andrew Rybchenko , Ashwin Sekhar T K , "John W. Linville" , Ciara Loftus , Chas Williams , "Min Hu (Connor)" , Gaetan Rivet , Dongdong Liu , Yisen Zhuang , Konstantin Ananyev , Qiming Yang , Jakub Grajciar , Tetsuya Mukawa , Jakub Palider , Tomasz Duszynski , Sachin Saxena , Hemant Agrawal Subject: Re: [PATCH v2 1/2] build: clarify configuration without IOVA field in mbuf Date: Thu, 09 Mar 2023 13:12:51 +0100 Message-ID: <4250554.ejJDZkT8p0@thomas> In-Reply-To: References: <20230219115529.3260580-1-thomas@monjalon.net> <1921837.PYKUYFuaPT@thomas> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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-`` 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? > >> Meson build 0.63.0 already support deprecated a option by a new option. > >> When update to the new meson verion, the drivers' meson.build will not be modified. > > > > I don't understand this comment. > > I mean: the option "enable_iova_as_pa" need deprecated future. Why deprecating this option? > Based on this, I think we should limit 'enable_iova_as_pa' usage scope, this allows us to > reduce the amount of change effort when it's about to deprecated. I don't plan to deprecate this option. And in general, we should avoid deprecating a compilation option.