* [dpdk-dev] [PATCH 0/1] RFC: remove build-type CPU flag macros @ 2020-08-05 14:21 Bruce Richardson 2020-08-05 14:21 ` [dpdk-dev] [PATCH 1/1] doc: add deprecation notice for CPU build flags Bruce Richardson 0 siblings, 1 reply; 11+ messages in thread From: Bruce Richardson @ 2020-08-05 14:21 UTC (permalink / raw) To: dev; +Cc: techboard, Bruce Richardson I DPDK as part of our build on all architectures, we define a set of RTE_MACHINE_CPUFLAG values which are then used in the code. However, as best I can see, each of these macros just duplicates a shorter macro provided by the compiler, e.g. RTE_MACHINE_CPUFLAG_SSE3 == __SSE3__, RTE_MACHINE_CPUFLAG_ALTIVEC == __ALTIVEC__, etc. Therefore, I propose we remove these macros in 20.11 and just use the compiler provided ones directly. As such, I'm including a deprecation notice patch for this change. Please review and ack the deprecation notice if you approve. Thanks. Bruce Richardson (1): doc: add deprecation notice for CPU build flags doc/guides/rel_notes/deprecation.rst | 5 +++++ 1 file changed, 5 insertions(+) -- 2.25.1 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [dpdk-dev] [PATCH 1/1] doc: add deprecation notice for CPU build flags 2020-08-05 14:21 [dpdk-dev] [PATCH 0/1] RFC: remove build-type CPU flag macros Bruce Richardson @ 2020-08-05 14:21 ` Bruce Richardson 2020-08-05 14:23 ` Jerin Jacob 2020-08-05 14:57 ` [dpdk-dev] [dpdk-techboard] " Thomas Monjalon 0 siblings, 2 replies; 11+ messages in thread From: Bruce Richardson @ 2020-08-05 14:21 UTC (permalink / raw) To: dev; +Cc: techboard, 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> --- doc/guides/rel_notes/deprecation.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index ea4cfa7a4..68a63f345 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -17,6 +17,11 @@ Deprecation Notices can be got using the ``pip``, or ``pip3``, tool for downloading python packages. +* 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__. + * kvargs: The function ``rte_kvargs_process`` will get a new parameter for returning key match count. It will ease handling of no-match case. -- 2.25.1 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] [PATCH 1/1] doc: add deprecation notice for CPU build flags 2020-08-05 14:21 ` [dpdk-dev] [PATCH 1/1] doc: add deprecation notice for CPU build flags Bruce Richardson @ 2020-08-05 14:23 ` Jerin Jacob 2020-08-05 14:57 ` [dpdk-dev] [dpdk-techboard] " Thomas Monjalon 1 sibling, 0 replies; 11+ messages in thread From: Jerin Jacob @ 2020-08-05 14:23 UTC (permalink / raw) To: Bruce Richardson; +Cc: dpdk-dev, techboard On Wed, Aug 5, 2020 at 7:52 PM Bruce Richardson <bruce.richardson@intel.com> wrote: > > 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> Acked-by: Jerin Jacob <jerinj@marvell.com> > --- > doc/guides/rel_notes/deprecation.rst | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst > index ea4cfa7a4..68a63f345 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -17,6 +17,11 @@ Deprecation Notices > can be got using the ``pip``, or ``pip3``, tool for downloading python > packages. > > +* 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__. > + > * kvargs: The function ``rte_kvargs_process`` will get a new parameter > for returning key match count. It will ease handling of no-match case. > > -- > 2.25.1 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] [dpdk-techboard] [PATCH 1/1] doc: add deprecation notice for CPU build flags 2020-08-05 14:21 ` [dpdk-dev] [PATCH 1/1] doc: add deprecation notice for CPU build flags Bruce Richardson 2020-08-05 14:23 ` Jerin Jacob @ 2020-08-05 14:57 ` Thomas Monjalon 2020-08-05 15:07 ` Bruce Richardson 1 sibling, 1 reply; 11+ messages in thread From: Thomas Monjalon @ 2020-08-05 14:57 UTC (permalink / raw) To: Bruce Richardson; +Cc: dev, techboard 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] [dpdk-techboard] [PATCH 1/1] doc: add deprecation notice for CPU build flags 2020-08-05 14:57 ` [dpdk-dev] [dpdk-techboard] " Thomas Monjalon @ 2020-08-05 15:07 ` Bruce Richardson 2020-08-05 15:15 ` Thomas Monjalon 0 siblings, 1 reply; 11+ messages in thread From: Bruce Richardson @ 2020-08-05 15:07 UTC (permalink / raw) To: Thomas Monjalon; +Cc: dev, techboard 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. :-) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] [dpdk-techboard] [PATCH 1/1] doc: add deprecation notice for CPU build flags 2020-08-05 15:07 ` Bruce Richardson @ 2020-08-05 15:15 ` Thomas Monjalon 2020-08-05 16:45 ` Bruce Richardson 0 siblings, 1 reply; 11+ messages in thread From: Thomas Monjalon @ 2020-08-05 15:15 UTC (permalink / raw) To: Bruce Richardson; +Cc: dev, techboard 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] [dpdk-techboard] [PATCH 1/1] doc: add deprecation notice for CPU build flags 2020-08-05 15:15 ` Thomas Monjalon @ 2020-08-05 16:45 ` Bruce Richardson 2020-08-05 17:02 ` Thomas Monjalon 2020-08-06 21:41 ` Ferruh Yigit 0 siblings, 2 replies; 11+ messages in thread From: Bruce Richardson @ 2020-08-05 16:45 UTC (permalink / raw) To: Thomas Monjalon; +Cc: dev, techboard 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. /Bruce ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] [dpdk-techboard] [PATCH 1/1] doc: add deprecation notice for CPU build flags 2020-08-05 16:45 ` Bruce Richardson @ 2020-08-05 17:02 ` Thomas Monjalon 2020-08-06 16:01 ` Thomas Monjalon 2020-08-06 21:41 ` Ferruh Yigit 1 sibling, 1 reply; 11+ messages in thread From: Thomas Monjalon @ 2020-08-05 17:02 UTC (permalink / raw) To: Bruce Richardson; +Cc: dev, techboard 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> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] [dpdk-techboard] [PATCH 1/1] doc: add deprecation notice for CPU build flags 2020-08-05 17:02 ` Thomas Monjalon @ 2020-08-06 16:01 ` Thomas Monjalon 0 siblings, 0 replies; 11+ messages in thread From: Thomas Monjalon @ 2020-08-06 16:01 UTC (permalink / raw) To: dev; +Cc: Bruce Richardson, techboard 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> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] [dpdk-techboard] [PATCH 1/1] doc: add deprecation notice for CPU build flags 2020-08-05 16:45 ` Bruce Richardson 2020-08-05 17:02 ` Thomas Monjalon @ 2020-08-06 21:41 ` Ferruh Yigit 2020-08-07 13:48 ` Thomas Monjalon 1 sibling, 1 reply; 11+ messages in thread From: Ferruh Yigit @ 2020-08-06 21:41 UTC (permalink / raw) To: Bruce Richardson, Thomas Monjalon; +Cc: dev, techboard On 8/5/2020 5:45 PM, Bruce Richardson wrote: > 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. > Sounds reasonable, Acked-by: Ferruh Yigit <ferruh.yigit@intel.com> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] [dpdk-techboard] [PATCH 1/1] doc: add deprecation notice for CPU build flags 2020-08-06 21:41 ` Ferruh Yigit @ 2020-08-07 13:48 ` Thomas Monjalon 0 siblings, 0 replies; 11+ messages in thread From: Thomas Monjalon @ 2020-08-07 13:48 UTC (permalink / raw) To: Bruce Richardson; +Cc: dev, techboard, Ferruh Yigit 06/08/2020 23:41, Ferruh Yigit: > On 8/5/2020 5:45 PM, Bruce Richardson wrote: > > 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. > > > > Sounds reasonable, > > Acked-by: Ferruh Yigit <ferruh.yigit@intel.com> Applied ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-08-07 13:48 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-05 14:21 [dpdk-dev] [PATCH 0/1] RFC: remove build-type CPU flag macros Bruce Richardson 2020-08-05 14:21 ` [dpdk-dev] [PATCH 1/1] doc: add deprecation notice for CPU build flags Bruce Richardson 2020-08-05 14:23 ` Jerin Jacob 2020-08-05 14:57 ` [dpdk-dev] [dpdk-techboard] " Thomas Monjalon 2020-08-05 15:07 ` Bruce Richardson 2020-08-05 15:15 ` Thomas Monjalon 2020-08-05 16:45 ` Bruce Richardson 2020-08-05 17:02 ` Thomas Monjalon 2020-08-06 16:01 ` Thomas Monjalon 2020-08-06 21:41 ` Ferruh Yigit 2020-08-07 13:48 ` Thomas Monjalon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).