Re: [dpdk-dev] [RFC PATCH 0/5] rework feature enabling macros for compatibility

[Thomas Monjalon <thomas@monjalon.net>]

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.