From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9D3A3A04B5; Wed, 30 Sep 2020 18:13:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3A9081D51F; Wed, 30 Sep 2020 18:13:00 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id DC5F21D516 for ; Wed, 30 Sep 2020 18:12:56 +0200 (CEST) IronPort-SDR: m0xrDCYvxO+ouWqwG8e+MqgoHpHvTXfUS/aHp2vrNVcotQv0NFgXYJJ61Ke4+ss3o3IWuejFpB raFmKggPdkRw== X-IronPort-AV: E=McAfee;i="6000,8403,9760"; a="159821759" X-IronPort-AV: E=Sophos;i="5.77,322,1596524400"; d="scan'208";a="159821759" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2020 09:12:55 -0700 IronPort-SDR: GJxKnARnf1P3DfAGLTPlqelmW5Y4uMIzqzusONbQDIQSZLomM27R1IxyAxw9OymjFMETC2ZyLw jo+QymXW+A5w== X-IronPort-AV: E=Sophos;i="5.77,322,1596524400"; d="scan'208";a="312638844" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.229.39]) ([10.213.229.39]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Sep 2020 09:12:53 -0700 To: Bruce Richardson , david.marchand@redhat.com Cc: dev@dpdk.org References: <20200916164429.244847-1-bruce.richardson@intel.com> From: Ferruh Yigit Message-ID: <4d0ad859-a0bc-7a75-ef1c-fa5c794a07d8@intel.com> Date: Wed, 30 Sep 2020 17:12:50 +0100 MIME-Version: 1.0 In-Reply-To: <20200916164429.244847-1-bruce.richardson@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [RFC PATCH 0/5] rework feature enabling macros for compatibility X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 9/16/2020 5:44 PM, Bruce Richardson wrote: > As flagged previously on-list, there are a number of macros used to specify > what libs and drivers are enabled in the build which differ from the > equivalents used with make. This patchset is one possible approach to > fixing these, but as part of the investigation some issues were hit where > I'd like additional input to ensure we are ok with the approach taken in > this set. > > First, a problem statement: > > * While the make build defines generally followed a pattern, there were > many instances where the defines were unique. These can be seen in the > values defined in patch 4. > > * The NIC PMDs had two separate standards for the defines - some (the > physical device drivers) tended to have the _PMD at the end of the > macros, while the virtual drivers had it in the middle. Since the > majority seemed to go with it at the end, meson chose this option. > However, as can be seen from patch 4, a number now need special handling > for compatibility +1 to all X_PMD macros. > > * This "_PMD" at the end made its way into other device classes, such as > crypto and event, but it appears that the standard for these classes from > make is in fact the opposite. Therefore we have had for the last 2+ years > conflicting macros for crypto, compression and event classes. > > * There is also the question of how important compatibility for these > macros is, especially since we have had numerous incompatibilities > without it being reported before. There is also the issue of the > deprecation process for macros, since these are not part of any ABI. > > What's done in this set: > > * Firstly, and missing dependencies on apps or examples had to be fixed, > where a dependency was missed because it was never needed due to the code > being stripped out because of a missing macro. > > * Secondly, since it is likely that use of the defines from make is more > widespread than those from meson, the defines for the crypto, compression > and event classes are changed to align with the make values. Just in case > though, temporary code is added to drivers/meson.build to redefine the > old meson values too, and a deprecation notice is added for these. The > hope is that we can then remove this temporary code in the next release, > leaving us with just one macro style for each driver class. > > * Thirdly, we add an additional set of backward compatibility macros for > the ~30 special-cases, where the meson macro template does not match that > defined for make. Again, this is intended to be temporary and a > deprecation notice is given for the macros in that file. > Why we need this backward compatibility? The macros are to enable/disable a module, so isn't it DPDK internal. If we enable the macros for new naming convention and update the build system and code for new macros, will it affect the end user? > > * Finally, we replace all instances of the old macros in the codebase with > the newer versions. While the work done in the first four patches (steps > 1-3 above) should be ok to backport, this final patch is not suitable for > backporting. However, it is relatively simple to produce a new patch for > backporting which allow either old or new values to be used in macros. > > > Open issues/considerations after this patch: > > * We still have inconsistencies in our driver macro and naming templates. > This is just a nice-to-have, but if people are ok with generally having a > breakage in our macro defines, we could clean this up a lot further. > Notice how 'net', 'regex' and 'vdpa' have '_PMD' at the end, while most > others have it before the name. Notice also that many device classes have > the class at the end of the template, while bbdev has it in the middle. > $ git grep config_flag_fmt -- drivers/*/meson.build > drivers/baseband/meson.build:config_flag_fmt = 'RTE_LIBRTE_PMD_BBDEV_@0@' > drivers/bus/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_BUS' > drivers/common/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_COMMON' > drivers/compress/meson.build:config_flag_fmt = 'RTE_LIBRTE_PMD_@0@' > drivers/crypto/meson.build:config_flag_fmt = 'RTE_LIBRTE_PMD_@0@' > drivers/event/meson.build:config_flag_fmt = 'RTE_LIBRTE_PMD_@0@_EVENTDEV' > drivers/mempool/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_MEMPOOL' > drivers/net/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_PMD' > drivers/raw/meson.build:config_flag_fmt = 'RTE_LIBRTE_PMD_@0@_RAWDEV' > drivers/regex/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_PMD' > drivers/vdpa/meson.build:config_flag_fmt = 'RTE_LIBRTE_@0@_PMD' > > * Are we ok to remove the older macros after one release of deprecation, or > do we need to wait to next API window. > > * I have not made any changes to the docs for this, since I expect that > these macros are already covered by the doc changes in the make removal > set. > > Reviews and comments welcome. > > Bruce Richardson (5): > app: fix missing dependencies > examples/l2fwd-crypto: fix missing dependency > meson: fix compatibility with make build defines > build: add defines for compatibility with make build > build: replace use of old build macros > > app/test-crypto-perf/meson.build | 3 + > app/test-pmd/cmdline.c | 8 +- > app/test-pmd/meson.build | 12 +++ > app/test-pmd/parameters.c | 12 +-- > app/test-pmd/testpmd.c | 24 ++--- > app/test-pmd/testpmd.h | 4 +- > app/test/meson.build | 3 + > app/test/test_eal_flags.c | 4 +- > config/meson.build | 3 +- > config/rte_compatibility_defines.h | 129 +++++++++++++++++++++++++++ > config/rte_config.h | 1 + > doc/guides/rel_notes/deprecation.rst | 17 ++++ > drivers/compress/meson.build | 2 +- > drivers/crypto/meson.build | 2 +- > drivers/event/meson.build | 2 +- > drivers/meson.build | 15 ++++ > examples/l2fwd-crypto/meson.build | 3 + > 17 files changed, 214 insertions(+), 30 deletions(-) > create mode 100644 config/rte_compatibility_defines.h >