
Programmer’s Guide, Release 18.11.0
For chunks of memory which must be IOVA-contiguous, it is recommended to use
rte_memzone_reserve() function with RTE_MEMZONE_IOVA_CONTIG flag specified. This
way, memory allocator will ensure that, whatever memory mode is in use, either reserved
memory will satisfy the requirements, or the allocation will fail.
There is no need to preallocate any memory at startup using -m or --socket-mem command-
line parameters, however it is still possible to do so, in which case preallocate memory will be
“pinned” (i.e. will never be released by the application back to the system). It will be possible
to allocate more hugepages, and deallocate those, but any preallocated pages will not be
freed. If neither -m nor --socket-mem were specified, no memory will be preallocated, and
all memory will be allocated at runtime, as needed.
Another available option to use in dynamic memory mode is --single-file-segments
command-line option. This option will put pages in single files (per memseg list), as opposed
to creating a file per page. This is normally not needed, but can be useful for use cases like
userspace vhost, where there is limited number of page file descriptors that can be passed to
VirtIO.
If the application (or DPDK-internal code, such as device drivers) wishes to receive notifica-
tions about newly allocated memory, it is possible to register for memory event callbacks via
rte_mem_event_callback_register() function. This will call a callback function any
time DPDK’s memory map has changed.
If the application (or DPDK-internal code, such as device drivers) wishes to
be notified about memory allocations above specified threshold (and have a
chance to deny them), allocation validator callbacks are also available via
rte_mem_alloc_validator_callback_register() function.
A default validator callback is provided by EAL, which can be enabled with a --socket-limit
command-line option, for a simple way to limit maximum amount of memory that can be used
by DPDK application.
Note: In multiprocess scenario, all related processes (i.e. primary process, and secondary
processes running with the same prefix) must be in the same memory modes. That is, if
primary process is run in dynamic memory mode, all of its secondary processes must be run
in the same mode. The same is applicable to --single-file-segments command-line
option - both primary and secondary processes must shared this mode.
• Legacy memory mode
This mode is enabled by specifying --legacy-mem command-line switch to the EAL. This
switch will have no effect on FreeBSD as FreeBSD only supports legacy mode anyway.
This mode mimics historical behavior of EAL. That is, EAL will reserve all memory at startup,
sort all memory into large IOVA-contiguous chunks, and will not allow acquiring or releasing
hugepages from the system at runtime.
If neither -m nor --socket-mem were specified, the entire available hugepage memory will
be preallocated.
• 32-bit support
Additional restrictions are present when running in 32-bit mode. In dynamic memory mode, by
default maximum of 2 gigabytes of VA space will be preallocated, and all of it will be on master
lcore NUMA node unless --socket-mem flag is used.
3.1. EAL in a Linux-userland Execution Environment 10