Re: [dpdk-dev] [RFC PATCH v3 3/6] build: automatic NUMA and cpu counts detection

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

<snip>

> >
> > > >
> > > Part of the confusion arises from the fact that originally that was
> > > the only parameter set by this - and on x86 it still is. Perhaps
> > > this parameter needs to
> > Just wondering, for x86, what does it mean if we set the max_num_cores
> and max_numa_nodes based on dynamic detection for 'native' build?
> > ISA still remains the same as before. But, the build might not work on
> machines with higher number of cores and numa nodes.
> > At the same time, the build also might not work on a machine with a
> different ISA. The users need to be aware that the target machine has the
> same ISA and same number of cores/numa nodes as the target machine.
> >
> Yes, that is a fair summary.
> 
> > > be renamed to "isa-level" or "architecture-flag" or similar to
> > > reflect its meaning. This would then allow a new "machine" setting,
> > > which can be considered separately. The question then is how much
> > > that helps with the main issue under discussion, that of cores and numa
> node values.
> > If we rename it, we will have backward compatibility issue (i.e. 'native' build
> on x86 will have different meaning and whoever wants the original meaning,
> have to change to using this new name). Not sure about the complexity in
> meson scripts.
> >
> 
> Yep, it was just a thought to see if it could help in this situation.
> 
> >
> > >
> > > > But, I think other DPDK specific parameters should also be considered.
> > > > For ex: RTE_MAX_LCORE should have a particular value for 'generic'
> > > > build in
> > > all the supported architectures. The value could be different for
> > > each architecture, but it is fixed for the 'generic' build for a given
> architecture.
> > > Otherwise, the 'generic' build might not run on all the machines of
> > > that architecture.
> > > >
> > > > Similarly, for 'native' build, is there any reason not to include
> > > > other DPDK
> > > parameters as part of the definition? IMO, 'native' should refer to
> > > the entire build machine, not just the ISA. i.e. build on the target machine.
> > > >
> > >
> > > While I understand the idea here, it is somewhat complicated by the
> > > fact that the meson options given in "meson_options.txt" cannot be
> > > set by meson code, which means that when we change the machine flag
> > > to "native" we can only use or ignore the user-provided lcores and
> > > numa nodes setting - we have no way to change them and reflect those
> > > changes back to the user. :-( This leads to the situation in the
> > > discussion in this thread, where we start needing all sorts of magic
> > > values to indicate use of machine-type defaults or detected defaults.
> > I am wondering why we need to take the max_num_cores and
> max_numa_nodes from the user? This option was not provided in the make
> build system. I ask this question because for 'generic' this has to be a
> static/known configuration. For cross builds, this info can come (or derived)
> from the cross build file.
> > Was it supposed to be used in conjunction with 'native' build?
> >
> 
> Well, it was configurable in the build config files same as all other DPDK build
> settings with make. When working first on meson, I felt it was a setting the
> user might be likely to want to tune, which is why I put it into the
> meson_options.txt and nobody suggested otherwise on review [which is the
> reason why many of the current options are the way they are :-)].
> 
> From my side, I have a couple of unknowns:
> 1. How big a difference in terms of memory use etc. of DPDK does it make by
>    having really big values for these core/numa counts? If there is not much
>    difference, then there is indeed little value in having them configurable
>    at all, and we should just use big defaults and be done with it.
> 2. If there is a noticable difference in these settings, how many users are
>    going to want to actually go to the trouble of tweaking these?
> 3. How big an effort is it to switch to having these settings made entirely
>    dynamic at runtime? Doing so would naturally make the need for these
>    settings completely go away.
A lot of the usage seems to be in the test code. Are these constants exposed to the users?

> 
> With all that said, I'd be ok with a number of solutions. I'm ok to have these
> dropped as meson options and just have them specified in other ways, e.g.
> cross-file, or from meson.build files. [For x86, I'd tend towards having them
> defined in rte_config.h inside x86-specific ifdefs].
> Alternatively, I'm also happy enough with the proposed scheme here of
> allowing user override, with platform defaults using "0"-value and detection
> using "-1".
Ok, we will stick to the methods in this patch.

> 
> Regards,
> /Bruce