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

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

[Igor Gutorov]

Hi,

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?


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?

[1]: https://github.com/DPDK/dpdk/blob/3ee7a3e0e0e0f5a81a4b102a834697bc488fb32f/lib/eal/common/eal_common_options.c#L1815
[2]: https://github.com/DPDK/dpdk/blob/3ee7a3e0e0e0f5a81a4b102a834697bc488fb32f/lib/eal/common/eal_common_memory.c#L1103

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

[Dmitry Kozlyuk]

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:

https://elixir.bootlin.com/dpdk/v24.11/source/lib/mempool/rte_mempool.c#L93

> 
> [1]: https://github.com/DPDK/dpdk/blob/3ee7a3e0e0e0f5a81a4b102a834697bc488fb32f/lib/eal/common/eal_common_options.c#L1815
> [2]: https://github.com/DPDK/dpdk/blob/3ee7a3e0e0e0f5a81a4b102a834697bc488fb32f/lib/eal/common/eal_common_memory.c#L1103

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

[Stephen Hemminger]

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.