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 C8A03A04BC; Thu, 17 Sep 2020 19:59:42 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 975821D6CD; Thu, 17 Sep 2020 19:59:41 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 127F61C21F for ; Thu, 17 Sep 2020 19:59:40 +0200 (CEST) Received: from mx1-us1.ppe-hosted.com (unknown [10.110.50.143]) by dispatch1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id 6F30B20152; Thu, 17 Sep 2020 17:59:39 +0000 (UTC) Received: from us4-mdac16-13.at1.mdlocal (unknown [10.110.49.195]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id 6BF698009B; Thu, 17 Sep 2020 17:59:39 +0000 (UTC) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us1.ppe-hosted.com (unknown [10.110.49.105]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id E17D340078; Thu, 17 Sep 2020 17:59:38 +0000 (UTC) Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 8C53D9C0069; Thu, 17 Sep 2020 17:59:38 +0000 (UTC) Received: from [127.0.0.27] (10.17.10.39) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 17 Sep 2020 18:59:33 +0100 To: Bruce Richardson , CC: References: <20200916164429.244847-1-bruce.richardson@intel.com> From: Andrew Rybchenko Message-ID: Date: Thu, 17 Sep 2020 20:59:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 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: 7bit X-Originating-IP: [10.17.10.39] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.6.1012-25670.006 X-TM-AS-Result: No-28.702100-8.000000-10 X-TMASE-MatchedRID: HLMPCFyIyBPmLzc6AOD8DfHkpkyUphL9SExQHIFQcSsjRiu1AuxJTJsz uduG4YrxF7uMtOT7Yi/pYK2wc1TVdXMp9PZvqqsO9FQh3flUIh6teS443ymeUXt4azXv2W1ZK8L fiwWKYyP8uRjv83Q4NoiO16p825Ov80tbt9isD183aW/7bl6SZ8GcvcBoab2j4mJSqMd68jRWQQ fMvQmocxFjIqInsEvXt++Qx0U6098Bm1BZMJ5EIvw4wQxTs7Jm45mEQknxFDalCu6kKVgvEjMDQ zZFyyDniVJBkgB5slJQWiVMsVW1lXUP4kIIgasjB8FxO/BQHsKIWGvfT9ZpjJGJXR6jRFu40TV/ E4Hoomn5veT98pykgosBL5BIR4CRdBxnS9vVxvbG9W0D68BZzGsuPcPFgEg3srDwfHQQaK15a5j lCfYvEgLA9WbYzv8Qs94yZ+1wHKis2ZrnO9hFIn9EwA0OW8QlwJ63yQFkSDZUjspoiX02F4I/Ut NSjQv4C8FJm6bDnba0F0wsmVGCn4G/yDOSYBKbdDJl3p3e8vn+NefZIdSZXBw0HKhKjTfp5wxIy yhRieNmsbBXXbl2Z9NDXCGw7ssWtw+ir2TPiIpYcYljwpu4xAe5TGeGLGZPadstfHk0/23nRVN5 IqBTNq/UHxz6Qf8/8eW7KU5mDVolz4C9OtA2eyA502nCZ/9koae+ev6zOlI7FE26mju9O1Wmmn2 klZ6wPVa/URzklI+zbsnIt4z3sPI1YbpS1+avngIgpj8eDcC063Wh9WVqgtQdB5NUNSsi1GcRAJ RT6PP3FLeZXNZS4LU+KYi1qWO6ftwZ3X11IV0= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--28.702100-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.6.1012-25670.006 X-MDID: 1600365579-b2zCm6KEHUb0 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/20 7: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 > > * 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. > > * 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' As a generic direction I would vote for standard names which are based on directory structure: - RTE_LIBRTE_ETHDEV - RTE_DRIVER_NET_SFC - RTE_DRIVER_COMMON_MLX5 - RTE_DRIVER_BUS_PCI > * 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 >