Re: [dpdk-dev] Eliminate config/rte_config.h?

["David Harton (dharton)" <dharton@cisco.com>]

> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Thursday, November 12, 2020 11:33 AM
> To: David Harton (dharton) <dharton@cisco.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] Eliminate config/rte_config.h?
> 
> On Thu, Nov 12, 2020 at 03:48:20PM +0000, Bruce Richardson wrote:
> > On Thu, Nov 12, 2020 at 03:39:10PM +0000, David Harton (dharton) wrote:
> > > Hi folks,
> > >
> > >
> > >
> > > Been experimenting with DPDK 20.11 and the loss of the old "config"
> > > hierarchy.
> > >
> > >
> > >
> > > I wonder if anyone considered eliminating config/rte_config.h in
> > > favor of a config/dpdk_conf that can contain the default values at
> > > the start of the file but can be overridden with values later in the
> > > file similar to how the old config files worked?
> > >
> > >
> > >
> > > It just feels awkward to modify a versioned header file per build
> > > especially if multiple builds want to share the same repo but with
> > > different values specified in config/rte_config.h especially when
> > > "rte_build_config.h" is included at the very beginning of
> > > config/rte_config.h.
> > >
> > >
> > >
> > > Thoughts?
> > >
> > > Dave
> > >
> >
> > I'd personally be open to replacing it if we have a better solution.
> > Are there many values in it that you look to tune,

A couple that quickly come to mind are RTE_LOG_DP_LEVEL and RTE_BACKTRACE; but, doesn't a single tunable value suggest a different mechanism is needed?

> > because I believe
> > the general consensus is that we want to reduce the number of tunables
> > we have per DPDK build?

Sounds good.  But doesn't that imply the config knob (i.e. #define) should just be removed or minimally moved?  IOW, things in rte_config.h should be tunable values and if they aren't tunable then they should like be in component specific "private" header files?

> > To that end our main concern should be having
> > decent defaults, and thereafter we can see about the best mechanism to
> > allow easy overriding for edge-cases.
> >
> > Any early attempt at such a thing was tried [1], but unfortunately it
> > had issues so we need a new approach - possibly one as you had
> suggested.
> >
> Just sent another idea of what options might be possible:
> http://patches.dpdk.org/patch/84068/

That would be better.

What if we had a config/dpdk_conf with all the defaults defined using the old 'config' syntax and then tools just append any overrides as desired.  A simple tool could parse config/dpdk_conf to generate the appropriate rte_config.h instead of rte_build_config.h?

BTW, one of the reasons why I'm asking about a more "config" like approach to help ease switching between the make and meson build methods for platforms.  It may also help folks adopt the meson approach more easily.

Dave

> 
> Regards,
> /Bruce