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

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

[David Harton (dharton)]

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

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

[Bruce Richardson]

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, because I believe the
general consensus is that we want to reduce the number of tunables we have
per DPDK build?  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.

/Bruce

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

[Bruce Richardson]

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, because I believe the
> general consensus is that we want to reduce the number of tunables we have
> per DPDK build?  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/

Regards,
/Bruce

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

[David Harton (dharton)]

> -----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