Message ID | 20200916164429.244847-1-bruce.richardson@intel.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B6A4CA04B5; Wed, 16 Sep 2020 18:44:37 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 968D41D153; Wed, 16 Sep 2020 18:44:37 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 4727C1C43A for <dev@dpdk.org>; Wed, 16 Sep 2020 18:44:35 +0200 (CEST) IronPort-SDR: 1Kx7y3mB2xUUYuejL3Tsi3ej6luAWltsLCBgRrypnW7uOs4A4NBWwPNjyK2znzY+kLaH+6k2a6 e+qL9A2AYh/Q== X-IronPort-AV: E=McAfee;i="6000,8403,9746"; a="160441926" X-IronPort-AV: E=Sophos;i="5.76,433,1592895600"; d="scan'208";a="160441926" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2020 09:44:34 -0700 IronPort-SDR: LcwQKMGr93LzVRBiIETtmDLh3p8QqzsMb2WcgeAclDPjpEcX6dP+Tt+2G61xb54inn9oxyvAYK xMNWnHXWA73Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.76,433,1592895600"; d="scan'208";a="483381354" Received: from silpixa00399126.ir.intel.com ([10.237.222.27]) by orsmga005.jf.intel.com with ESMTP; 16 Sep 2020 09:44:33 -0700 From: Bruce Richardson <bruce.richardson@intel.com> To: david.marchand@redhat.com Cc: dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com> Date: Wed, 16 Sep 2020 17:44:24 +0100 Message-Id: <20200916164429.244847-1-bruce.richardson@intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [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 <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 Sender: "dev" <dev-bounces@dpdk.org> |
Series |
rework feature enabling macros for compatibility
|
|
Message
Bruce Richardson
Sept. 16, 2020, 4:44 p.m. UTC
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' * 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
Comments
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 >
On Thu, Sep 17, 2020 at 08:59:26PM +0300, Andrew Rybchenko wrote: > 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 > Definite +1, and it would be good if we standardized the .so names like that too. The open question is how much backward compatibility needs to be maintained for macros (and also too for .so names)? With this patchset, I've aimed very much to keep strict compatibility for now.
On 9/18/20 11:41 AM, Bruce Richardson wrote: > On Thu, Sep 17, 2020 at 08:59:26PM +0300, Andrew Rybchenko wrote: >> 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 >> > > Definite +1, and it would be good if we standardized the .so names like > that too. > > The open question is how much backward compatibility needs to be maintained > for macros (and also too for .so names)? With this patchset, I've aimed > very much to keep strict compatibility for now. I think it is really good. Technically it does not look hard to provide backward compatibility for macros, so I'd keep it up to but not including 21.11 (next LTS?). Same for .so names, if it is not a problem. If we approve the decision on naming, all new entities must follow it from the very beginning.
On 9/18/2020 9:59 AM, Andrew Rybchenko wrote: > On 9/18/20 11:41 AM, Bruce Richardson wrote: >> On Thu, Sep 17, 2020 at 08:59:26PM +0300, Andrew Rybchenko wrote: >>> 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 >>> >> >> Definite +1, and it would be good if we standardized the .so names like >> that too. >> >> The open question is how much backward compatibility needs to be maintained >> for macros (and also too for .so names)? With this patchset, I've aimed >> very much to keep strict compatibility for now. > > I think it is really good. Technically it does not look hard to > provide backward compatibility for macros, so I'd keep it up to > but not including 21.11 (next LTS?). Same for .so names, if it > is not a problem. > > If we approve the decision on naming, all new entities must > follow it from the very beginning. > +1
On Wed, Sep 16, 2020 at 6:44 PM Bruce Richardson <bruce.richardson@intel.com> 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. The main use I can think of for an application is controlling calls to specific drivers API. This is how we caught this issue, with testpmd silently dropping code/feature. My impression is that people are only starting building with meson now they are forced to: even DTS only recently started building with it. This is why I don't think the absence of complaints is a good indicator. > > 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. The series looks good to me. Thanks for coming with this quickly. > 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' I can see the meson implementation kept a part of the chaotic aspect of the make implementation ;-). I like Andrew proposal. +1 even if this is "nice to have". Cleaning the .so names is nice too, and I don't see an impact for applications now that we provide a pkgconfig file. > > * Are we ok to remove the older macros after one release of deprecation, or > do we need to wait to next API window. Waiting for one release or more won't make a difference for people who only upgrade with LTS. If we go with the change, I'd rather drop the API compatibility in the next release 21.02, as this is an "easy" thing to fix for applications that recompile with intermediate releases.
18/09/2020 10:41, Bruce Richardson: > On Thu, Sep 17, 2020 at 08:59:26PM +0300, Andrew Rybchenko wrote: > > On 9/16/20 7:44 PM, Bruce Richardson wrote: > > > * 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 I would prefer RTE_LIB_ETHDEV (instead of LIBRTE). If we plan to rework all flags, I would even prefer - DPDK_LIB_ETHDEV - DPDK_DRIVER_BUS_PCI > Definite +1, and it would be good if we standardized the .so names like > that too. +1 to align .so names for clarity. > The open question is how much backward compatibility needs to be maintained > for macros (and also too for .so names)? With this patchset, I've aimed > very much to keep strict compatibility for now. As David said, the compatibility is mostly for apps using driver-specific API. We could also consider that the compatibility break was announced as part of the makefile removal. In any case, it is not ABI sensitive, so no need to wait 21.11. If choosing between a compilation flag breakage in 21.02 or 20.11, I would prefer 20.11 where legacy build system is removed. About LTS, we may want to have some patches targetted to 18.11 and 19.11, to allow a transparent switch between make and meson.
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 >
On Wed, Sep 30, 2020 at 05:12:50PM +0100, Ferruh Yigit wrote: > 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? > I'd love to be able to just take this option, but the macros are used to indicate to applications what drivers or other components can be expected to be available - much as the case for testpmd. Ideally, they should not be necessary. I think the best approach is that proposed earlier on this thread - we keep backward compatibility as much as possible in this release, but add in a new set of standardized macros and a deprecation notice about the old ones. I hope to work on a new rev of this patchset shortly. /Bruce
> -----Original Message----- > From: Thomas Monjalon <thomas@monjalon.net> > Sent: Wednesday, September 23, 2020 1:46 PM > To: Richardson, Bruce <bruce.richardson@intel.com> > Cc: Andrew Rybchenko <arybchenko@solarflare.com>; > david.marchand@redhat.com; dev@dpdk.org; Yigit, Ferruh > <ferruh.yigit@intel.com> > Subject: Re: [dpdk-dev] [RFC PATCH 0/5] rework feature enabling macros for > compatibility > > 18/09/2020 10:41, Bruce Richardson: > > On Thu, Sep 17, 2020 at 08:59:26PM +0300, Andrew Rybchenko wrote: > > > On 9/16/20 7:44 PM, Bruce Richardson wrote: > > > > * 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 > > I would prefer RTE_LIB_ETHDEV (instead of LIBRTE). > If we plan to rework all flags, I would even prefer > - DPDK_LIB_ETHDEV > - DPDK_DRIVER_BUS_PCI Since everything else in DPDK uses an RTE prefix, I think it might be sensible to keep that here too: * RTE_LIB_ETHDEV * RTE_PMD_BUS_PCI * RTE_PMD_NET_IXGBE * RTE_PMD_CRYPTO_KASUMI etc. > > Definite +1, and it would be good if we standardized the .so names like > > that too. > > +1 to align .so names for clarity. > I'd really like this, but need to see the implications for any drivers which may be multi-function, like QAT which has a single .so file. > > The open question is how much backward compatibility needs to be > maintained > > for macros (and also too for .so names)? With this patchset, I've aimed > > very much to keep strict compatibility for now. > > As David said, the compatibility is mostly for apps using driver-specific > API. > We could also consider that the compatibility break was announced > as part of the makefile removal. > In any case, it is not ABI sensitive, so no need to wait 21.11. > If choosing between a compilation flag breakage in 21.02 or 20.11, > I would prefer 20.11 where legacy build system is removed. > > About LTS, we may want to have some patches targetted to 18.11 and 19.11, > to allow a transparent switch between make and meson. > Any more thoughts on this? Any change to standardize the library names is going to have to be done in 20.11 if it's to be done at all, since that would be an ABI break. I'd tend towards only changing the defines for 21.02, but if lots of other things are changing too, perhaps it's not worthwhile waiting. /Bruce
30/09/2020 18:49, Richardson, Bruce: > From: Thomas Monjalon <thomas@monjalon.net> > > 18/09/2020 10:41, Bruce Richardson: > > > On Thu, Sep 17, 2020 at 08:59:26PM +0300, Andrew Rybchenko wrote: > > > > On 9/16/20 7:44 PM, Bruce Richardson wrote: > > > > > * 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 > > > > I would prefer RTE_LIB_ETHDEV (instead of LIBRTE). > > If we plan to rework all flags, I would even prefer > > - DPDK_LIB_ETHDEV > > - DPDK_DRIVER_BUS_PCI > > Since everything else in DPDK uses an RTE prefix, Not everything. The applications and scripts are prefixed with dpdk- > I think it might be sensible to keep that here too: > > * RTE_LIB_ETHDEV > * RTE_PMD_BUS_PCI PMD before BUS looks weird. > * RTE_PMD_NET_IXGBE > * RTE_PMD_CRYPTO_KASUMI > etc. > > > > Definite +1, and it would be good if we standardized the .so names like > > > that too. > > > > +1 to align .so names for clarity. > > > I'd really like this, but need to see the implications for any drivers which may be multi-function, like QAT which has a single .so file. > > > > The open question is how much backward compatibility needs to be > > maintained > > > for macros (and also too for .so names)? With this patchset, I've aimed > > > very much to keep strict compatibility for now. > > > > As David said, the compatibility is mostly for apps using driver-specific > > API. > > We could also consider that the compatibility break was announced > > as part of the makefile removal. > > In any case, it is not ABI sensitive, so no need to wait 21.11. > > If choosing between a compilation flag breakage in 21.02 or 20.11, > > I would prefer 20.11 where legacy build system is removed. > > > > About LTS, we may want to have some patches targetted to 18.11 and 19.11, > > to allow a transparent switch between make and meson. > > > > Any more thoughts on this? > Any change to standardize the library names is going to have to be done in 20.11 if it's to be done at all, since that would be an ABI break. I'd tend towards only changing the defines for 21.02, but if lots of other things are changing too, perhaps it's not worthwhile waiting.