Re: [dpdk-dev] [dpdk-techboard] [PATCH 1/1] doc: add deprecation notice for CPU build flags

[Thomas Monjalon <thomas@monjalon.net>]

Any other opinions?

05/08/2020 19:02, Thomas Monjalon:
> 05/08/2020 18:45, Bruce Richardson:
> > On Wed, Aug 05, 2020 at 05:15:31PM +0200, Thomas Monjalon wrote:
> > > 05/08/2020 17:07, Bruce Richardson:
> > > > On Wed, Aug 05, 2020 at 04:57:42PM +0200, Thomas Monjalon wrote:
> > > > > 05/08/2020 16:21, Bruce Richardson:
> > > > > > The RTE_MACHINE_CPUFLAGS_* macros in DPDK build just duplicate info from
> > > > > > the compiler macros, so we can remove them and just use the compiler
> > > > > > versions directly.
> > > > > > 
> > > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > > > ---
> > > > > > --- a/doc/guides/rel_notes/deprecation.rst
> > > > > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > > > > +* build macros: The macros defining RTE_MACHINE_CPUFLAG_* will be removed
> > > > > > +  from the build. The information provided by these macros is available
> > > > > > +  through standard compiler macros. For example, RTE_MACHINE_CPUFLAG_SSE3
> > > > > > +  duplicates the compiler-provided macro __SSE3__.
> > > > > 
> > > > > I see 2 advantages of having alias:
> > > > > 	- if 2 compilers differ, we can manage
> > > > > 	- we can find all such macros with grep RTE_MACHINE_CPUFLAG
> > > > >
> > > > 
> > > > Sure, if you think it's worthwhile keeping them, we can do so. It's just
> > > > right now they seem to be largely a waste of space. For #2, I'm not sure
> > > > when we would want to grep for them all, except possibly to remove them.
> > > > :-)
> > > 
> > > For instance, in a lib, I grep where we have CPU specific code.
> > > 
> > > We probably need more opinions, I can change my mind.
> > > 
> > Yes, we need some more opinions here.
> > 
> > For the above point, yes it's useful to be able to grep for these things,
> > but it does assume that everybody uses the DPDK-defines and doesn't use the
> > compiler ones directly. There are a few instances where there seems to be
> > x86, ARM or PPC compiler flags already directly used in the code.
> > 
> > As well as brevity, the other big reason I see for removing them is to
> > avoid having to maintain these lists of flags for future use. Right now,
> > with -march=skylake-avx512, gcc will define 7 different AVX feature flags.
> > DPDK, on the other hand, only provides equivalent defines for 3 of them.
> > We have no automatic way of pulling all newly added flags from gcc/clang
> > into our build, so we just add them on an as-needed basis, which makes it
> > more awkward for those adding new features that may depend on the flags. If
> > we always try to add in all flags to keep things in sync, we are just
> > duplicating the efforts the compiler authors have already done for us, and
> > wasting the effort for those flags that are unused.
> 
> You see, you can provide good arguments :)
> Maybe some of them deserve to be part of the patch.
> 
> Acked-by: Thomas Monjalon <thomas@monjalon.net>