Re: eal: -n or -r options are ignored when --in-memory is used

[Stephen Hemminger <stephen@networkplumber.org>]

On Thu, 5 Dec 2024 00:50:24 +0300
Dmitry Kozlyuk <dmitry.kozliuk@gmail.com> wrote:

> Hi Igor,
> 
> 2024-10-23 02:25 (UTC+0300), Igor Gutorov:
> > I've noticed an issue of `rte_memory_get_nchannel()` or
> > `rte_memory_get_nrank()` always returning zero regardless of the -n or
> > -r options set.
> > 
> > I think this is due to `--in-memory` forcing `conf->no_shconf = 1`
> > [1], which leads to `rte_eal_memdevice_init()` never being executed
> > [2].
> > 
> > I do not fully understand the context of the code, but I can submit a
> > patch that simply removes the `internal_conf->no_shconf == 0` check in
> > `rte_eal_memory_init()` and so always calls
> > `rte_eal_memdevice_init()`. Would that be ok or is there a better way?
> > Alternatively, does `(internal_conf->no_shconf == 0 ||
> > internal_conf->in_memory == 1) && ...` make sense here?  
> 
> Well spotted! Yes, the check seems unneeded.
> 
> > And one more thing, the 9.1.4 section of the getting started guide
> > states that the number of memory ranks is auto-detected by default,
> > but I can't find any code that performs the auto-detection - am I
> > missing something, or is the documentation wrong here?  
> 
> The doc is clearly wrong.
> Git says this piece originates from TestPMD documentation,
> so maybe "auto-detected" refers to some defaults for mempools:

Doc should be reworded to some thing like "if not defined, reasonable default
values are used instead".  It is difficult to do auto-detection of memory layout
optimum spread. The Linux kernel provides no visible API for finding out;
and the only way I know is digging into DMI data (see dmidecode). But DMI
data is only readable as root, can be wrong, and doesn't really match in a cloud
environment.