[PATCH v2 4/6] eal/memory: get rid of global VA space limits

[Bruce Richardson]

On Fri, Mar 13, 2026 at 04:06:35PM +0000, Anatoly Burakov wrote:
> Currently, all VA space reservations take into account global memory limit.
> The original intent was to limit memory allocations to however many NUMA
> nodes the machine had taking into the account that socket ID's may be
> discontiguous. Since we have had "socket count" API for while and it gives
> us correct NUMA node count, taking discontiguousness into account, we can
> relax the total limits and remove the restrictions, and let VA space usage
> scale with NUMA nodes.
> 
> The only place where we actually require a hard limit is in 32-bit code,
> where we cannot allocate more than 2G of VA space.
> 
> Signed-off-by: Anatoly Burakov <anatoly.burakov at intel.com>

Acked-by: Bruce Richardson <bruce.richardson at intel.com>

Asking AI about this patch flags an issue whereby the contigmem driver does
not guarantee the number of buffers is >0, which can cause issues. However,
that's better fixed in contigmem.

One additional comment inline below.

> ---
>  config/arm/meson.build                        |  1 -
>  config/meson.build                            |  5 ----
>  .../prog_guide/env_abstraction_layer.rst      |  2 --
>  lib/eal/common/eal_common_dynmem.c            | 13 +++------
>  lib/eal/freebsd/eal_memory.c                  | 28 +++----------------
>  lib/eal/linux/eal_memory.c                    | 10 +++----
>  6 files changed, 13 insertions(+), 46 deletions(-)
> 
> diff --git a/config/arm/meson.build b/config/arm/meson.build
> index 523b0fc0ed..3b03f5e31b 100644
> --- a/config/arm/meson.build
> +++ b/config/arm/meson.build
> @@ -69,7 +69,6 @@ part_number_config_arm = {
>          'flags': [
>              ['RTE_MACHINE', '"neoverse-n1"'],
>              ['RTE_ARM_FEATURE_ATOMICS', true],
> -            ['RTE_MAX_MEM_MB', 1048576],
>              ['RTE_MAX_LCORE', 256],
>              ['RTE_MAX_NUMA_NODES', 8]
>          ]
> diff --git a/config/meson.build b/config/meson.build
> index 02e2798cca..f68f1f5f53 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -383,11 +383,6 @@ dpdk_conf.set('RTE_PKTMBUF_HEADROOM', get_option('pkt_mbuf_headroom'))
>  dpdk_conf.set('RTE_MAX_VFIO_GROUPS', 64)
>  dpdk_conf.set('RTE_DRIVER_MEMPOOL_BUCKET_SIZE_KB', 64)
>  dpdk_conf.set('RTE_LIBRTE_DPAA2_USE_PHYS_IOVA', true)
> -if dpdk_conf.get('RTE_ARCH_64')
> -    dpdk_conf.set('RTE_MAX_MEM_MB', 524288)
> -else # for 32-bit we need smaller reserved memory areas
> -    dpdk_conf.set('RTE_MAX_MEM_MB', 2048)
> -endif
>  if get_option('mbuf_refcnt_atomic')
>      dpdk_conf.set('RTE_MBUF_REFCNT_ATOMIC', true)
>  endif
> diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
> index 04368a3950..63e0568afa 100644
> --- a/doc/guides/prog_guide/env_abstraction_layer.rst
> +++ b/doc/guides/prog_guide/env_abstraction_layer.rst
> @@ -208,8 +208,6 @@ variables:
>    can have (where "type" is defined as "page size + NUMA node" combination)

Is the RTE_MAX_MEMSEG_PER_TYPE value still necessary?

>  * ``RTE_MAX_MEM_MB_PER_TYPE`` controls how much megabytes of memory each
>    memory type can address
> -* ``RTE_MAX_MEM_MB`` places a global maximum on the amount of memory
> -  DPDK can reserve
>
<snip>