> -----Original Message----- > From: Bruce Richardson <bruce.richard...@intel.com> > Sent: Thursday, November 12, 2020 11:33 AM > To: David Harton (dharton) <dhar...@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
