public inbox for dev@dpdk.org
 help / color / mirror / Atom feed
From: Anatoly Burakov <anatoly.burakov@intel.com>
To: dev@dpdk.org
Subject: [PATCH v2 0/6] Make VA reservation limits configurable
Date: Fri, 13 Mar 2026 16:06:31 +0000	[thread overview]
Message-ID: <cover.1773417833.git.anatoly.burakov@intel.com> (raw)
In-Reply-To: <cover.1773225702.git.anatoly.burakov@intel.com>

Currently, the VA space reservation is governed by a combination of a few
values:

- Total max VA space (512G for most platforms, 1T for some, 2G for 32-bit) - Max
memory per memory type - Max pages per memory type

The "memory" type is defined as unique combination of NUMA node and page size.
The reason why there are two limits is because for large pages, having large
segment limit causes runaway multi-terabyte reservations, while for smaller
pages, having large memory limit causes hundreds of thousands of huge page
slots. The total maximum memory size was originally intended as a safeguard
against discontiguous NUMA nodes, but this has since been fixed by EAL API
explicitly supporting discontiguous NUMA nodes, so this is no longer a problem.

In addition to that, each memory type was split into multiple segment lists,
with the idea that it should be easier for a secondary process to reserve
multiple smaller chunks at discontiguous addresses than it is to reserve a large
single chunk of memory. It is unknown whether this actually makes a difference,
but what *is* known is that it's a source of additional complexity with memory
reservation, as well as a source of gratuitous memory reservation limits placed
on DPDK.

This patchset attempts to simplify and improve this situation in a few key
areas:

- Get rid of global memory limits

Total memory usage can, and should, scale with NUMA sockets, and so now it does.

- Get rid of multiple segment lists per memory type

This removes two config options, and makes the address space reservations a lot
simpler.

- Allocate all memory segment lists as one big blob of memory

This further simplifies address space reservations.

- Use memory size limits instead of segments limits

Despite smaller page sizes still needing limits on number of segments, they are
directly translated into memory size limits at init time, so that all limits the
VA space reservation ever sees are expressed in bytes, not segments. This
reduces complexity in how we manage the VA space reservations and work with our
limits.

- Do not use config constants directly

We switch to only invoking these constants once - at startup, when we are
discovering hugepage sizes available to the system. This allows us to be more
flexible in how we manage these limits.

- Add EAL command-line option to set per-page size limits

The final piece of the puzzle - the "more flexible in how we manage these
limits" part. This new parameter affords us more flexible VA space management,
including disabling specific page sizes entirely (by specifying 0 as the limit).
This allows increasing/decreasing VA space reservation limits without
recompiling DPDK.

v1 -> v2:
- Fix str_to_size not handling invalid input properly
- Move str_to_size autotests to string autotests file
- Fix hugepage file segment indexing to not use global constants
- More validation around VA reservation

Anatoly Burakov (6):
  eal: reject non-numeric input in str to size
  eal/memory: remove per-list segment and memory limits
  eal/memory: allocate all VA space in one go
  eal/memory: get rid of global VA space limits
  eal/memory: store default segment limits in config
  eal/memory: add page size VA limits EAL parameter

 app/test/test.c                               |   1 +
 app/test/test_eal_flags.c                     | 126 ++++++++++++
 app/test/test_malloc.c                        |  30 ---
 app/test/test_string_fns.c                    |  66 ++++++
 config/arm/meson.build                        |   1 -
 config/meson.build                            |   5 -
 config/rte_config.h                           |   2 -
 doc/guides/linux_gsg/linux_eal_parameters.rst |  13 ++
 .../prog_guide/env_abstraction_layer.rst      |  33 ++-
 lib/eal/common/eal_common_dynmem.c            | 192 ++++++++----------
 lib/eal/common/eal_common_memory.c            |  28 ++-
 lib/eal/common/eal_common_options.c           | 141 +++++++++++++
 lib/eal/common/eal_common_string_fns.c        |   4 +
 lib/eal/common/eal_filesystem.h               |  13 ++
 lib/eal/common/eal_internal_cfg.h             |   8 +
 lib/eal/common/eal_memcfg.h                   |   6 +
 lib/eal/common/eal_option_list.h              |   1 +
 lib/eal/common/eal_options.h                  |   1 +
 lib/eal/common/eal_private.h                  |  19 +-
 lib/eal/freebsd/eal.c                         |   6 +
 lib/eal/freebsd/eal_memory.c                  | 101 +++------
 lib/eal/linux/eal.c                           |   6 +
 lib/eal/linux/eal_memalloc.c                  |   4 +-
 lib/eal/linux/eal_memory.c                    | 170 ++++++++++------
 lib/eal/windows/eal.c                         |   6 +
 25 files changed, 687 insertions(+), 296 deletions(-)

-- 
2.47.3


  parent reply	other threads:[~2026-03-13 16:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-11 10:58 [PATCH v1 0/5] Make VA reservation limits configurable Anatoly Burakov
2026-03-11 10:58 ` [PATCH v1 1/5] eal/memory: always use one segment per memory type Anatoly Burakov
2026-03-11 10:58 ` [PATCH v1 2/5] eal/memory: allocate all VA space in one go Anatoly Burakov
2026-03-11 10:58 ` [PATCH v1 3/5] eal/memory: get rid of global VA space limits Anatoly Burakov
2026-03-11 10:58 ` [PATCH v1 4/5] eal/memory: store default segment limits in config Anatoly Burakov
2026-03-11 10:58 ` [PATCH v1 5/5] eal/memory: add page size VA limits EAL parameter Anatoly Burakov
2026-03-13 16:06 ` Anatoly Burakov [this message]
2026-03-13 16:06   ` [PATCH v2 1/6] eal: reject non-numeric input in str to size Anatoly Burakov
2026-03-13 16:16     ` Bruce Richardson
2026-03-13 16:06   ` [PATCH v2 2/6] eal/memory: remove per-list segment and memory limits Anatoly Burakov
2026-03-13 16:06   ` [PATCH v2 3/6] eal/memory: allocate all VA space in one go Anatoly Burakov
2026-03-13 16:06   ` [PATCH v2 4/6] eal/memory: get rid of global VA space limits Anatoly Burakov
2026-03-13 16:06   ` [PATCH v2 5/6] eal/memory: store default segment limits in config Anatoly Burakov
2026-03-13 16:06   ` [PATCH v2 6/6] eal/memory: add page size VA limits EAL parameter Anatoly Burakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1773417833.git.anatoly.burakov@intel.com \
    --to=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox