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 <[email protected]>
Acked-by: Bruce Richardson <[email protected]> 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>
