#
62ea63a6 |
| 18-Jun-2024 |
Stephen Hemminger <stephen@networkplumber.org> |
mem: remove type argument from internal routines
The type argument is carried through malloc heap routines but never used there. It is only used in rte_malloc for tracing.
Signed-off-by: Stephen He
mem: remove type argument from internal routines
The type argument is carried through malloc heap routines but never used there. It is only used in rte_malloc for tracing.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
show more ...
|
#
ae67895b |
| 08-Dec-2023 |
David Marchand <david.marchand@redhat.com> |
lib: add more logging helpers
Add helpers for logging messages in libraries instead of calling RTE_LOG() directly. Those helpers take care of adding a \n: this will make the transition to RTE_LOG_LI
lib: add more logging helpers
Add helpers for logging messages in libraries instead of calling RTE_LOG() directly. Those helpers take care of adding a \n: this will make the transition to RTE_LOG_LINE trivial.
Note: - for acl and sched libraries that still has some debug multilines messages, a direct call to RTE_LOG is used: this will make it easier to notice such special cases,
Signed-off-by: David Marchand <david.marchand@redhat.com>
show more ...
|
#
7e7b6762 |
| 26-May-2023 |
Kaisen You <kaisenx.you@intel.com> |
eal: enhance NUMA affinity heuristic
When a DPDK application is started on only one numa node, memory is allocated for only one socket. When interrupt threads use memory, memory may not be found on
eal: enhance NUMA affinity heuristic
When a DPDK application is started on only one numa node, memory is allocated for only one socket. When interrupt threads use memory, memory may not be found on the socket where the interrupt thread is currently located, and memory has to be reallocated on the hugepage, this operation will lead to performance degradation.
Fixes: 705356f0811f ("eal: simplify control thread creation") Fixes: 770d41bf3309 ("malloc: fix allocation with unknown socket ID")
Signed-off-by: Kaisen You <kaisenx.you@intel.com> Reviewed-by: Anatoly Burakov <anatoly.burakov@intel.com>
show more ...
|
#
46197f05 |
| 19-May-2023 |
Ruifeng Wang <ruifeng.wang@arm.com> |
malloc: simplify condition
The alt_elem is initialized to null. Checking only size hint flag is sufficient to return a proper value. Removed the redundant check.
Signed-off-by: Ruifeng Wang <ruifen
malloc: simplify condition
The alt_elem is initialized to null. Checking only size hint flag is sufficient to return a proper value. Removed the redundant check.
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com> Reviewed-by: Feifei Wang <feifei.wang2@arm.com> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
show more ...
|
#
2e2f0272 |
| 04-Apr-2023 |
David Marchand <david.marchand@redhat.com> |
mem: rework malloc heap init
rte_eal_memory_init() and rte_eal_malloc_heap_init() must be called in a common section taking rte_mcfg_mem_read_lock(). Split rte_eal_malloc_heap_init() in two so that
mem: rework malloc heap init
rte_eal_memory_init() and rte_eal_malloc_heap_init() must be called in a common section taking rte_mcfg_mem_read_lock(). Split rte_eal_malloc_heap_init() in two so that the mem lock is taken in rte_eal_init() making lock checks trivial (once annotated in the next patch).
Signed-off-by: David Marchand <david.marchand@redhat.com>
show more ...
|
#
3a0a3c88 |
| 04-Apr-2023 |
David Marchand <david.marchand@redhat.com> |
malloc: rework heap destroy
The destroy helper has been reworked to zero all the heap object but leave the lock untouched. The heap lock is then released through the standard API.
Signed-off-by: Da
malloc: rework heap destroy
The destroy helper has been reworked to zero all the heap object but leave the lock untouched. The heap lock is then released through the standard API.
Signed-off-by: David Marchand <david.marchand@redhat.com>
show more ...
|
#
f92b9ebe |
| 28-Jul-2022 |
Fidaullah Noonari <fidaullah.noonari@emumba.com> |
malloc: fix storage size for some allocations
The amount of memory to allocate from the system for heap expansion was calculated in a way that may yield one page more than needed. This could hit the
malloc: fix storage size for some allocations
The amount of memory to allocate from the system for heap expansion was calculated in a way that may yield one page more than needed. This could hit the allocation limit from the system or EAL. The allocation would fail despite enough memory being available.
In response to mail: https://inbox.dpdk.org/dev/CAEYuUWCnRZNwxiOHEeTHw0Gy9aFJRLZtvAG9g=smuUvUEMcFXg@mail.gmail.com/
A reproducer has been provided by Dmitry, see: https://inbox.dpdk.org/dev/20220922015212.03bfde66@sovereign/
Fixes: 07dcbfe0101f ("malloc: support multiprocess memory hotplug") Cc: stable@dpdk.org
Signed-off-by: Fidaullah Noonari <fidaullah.noonari@emumba.com> Acked-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
show more ...
|
#
ce2f7d47 |
| 25-May-2022 |
Fidaullah Noonari <fidaullah.noonari@emumba.com> |
malloc: fix allocation of almost hugepage size
If called to allocate memory of size is between multiple of hugepage size minus malloc_header_len and hugepage size, rte_malloc fails.
This fix replac
malloc: fix allocation of almost hugepage size
If called to allocate memory of size is between multiple of hugepage size minus malloc_header_len and hugepage size, rte_malloc fails.
This fix replaces malloc_elem_trailer_len with malloc_elem_overhead in try_expand_heap() to include malloc_elem_header_len when calculating n_seg.
Bugzilla ID: 800 Fixes: 07dcbfe0101f ("malloc: support multiprocess memory hotplug") Cc: stable@dpdk.org
Signed-off-by: Fidaullah Noonari <fidaullah.noonari@emumba.com> Acked-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
show more ...
|
#
4d8bdd8b |
| 04-May-2022 |
Anatoly Burakov <anatoly.burakov@intel.com> |
malloc: fix ASan handling for unmapped memory
Currently, when we free previously allocated memory, we mark the area as "freed" for ASan purposes (flag 0xfd). However, sometimes, freeing a malloc ele
malloc: fix ASan handling for unmapped memory
Currently, when we free previously allocated memory, we mark the area as "freed" for ASan purposes (flag 0xfd). However, sometimes, freeing a malloc element will cause pages to be unmapped from memory and re-backed with anonymous memory again. This may cause ASan's "use-after-free" error down the line, because the allocator will try to write into memory areas recently marked as "freed".
To fix this, we need to mark the unmapped memory area as "available", and fixup surrounding malloc element header/trailers to enable later malloc routines to safely write into new malloc elements' headers or trailers.
Bugzilla ID: 994 Fixes: 6cc51b1293ce ("mem: instrument allocator for ASan") Cc: stable@dpdk.org
Reported-by: David Marchand <david.marchand@redhat.com> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
show more ...
|
#
30a1de10 |
| 15-Feb-2022 |
Sean Morrissey <sean.morrissey@intel.com> |
lib: remove unneeded header includes
These header includes have been flagged by the iwyu_tool and removed.
Signed-off-by: Sean Morrissey <sean.morrissey@intel.com>
|
#
a0cc7be2 |
| 13-Nov-2021 |
Stephen Hemminger <stephen@networkplumber.org> |
mem: cleanup multiprocess resources
The mp action resources in malloc should be cleaned up via rte_eal_cleanup.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Acked-by: Anatoly Burak
mem: cleanup multiprocess resources
The mp action resources in malloc should be cleaned up via rte_eal_cleanup.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
show more ...
|
#
2edd037c |
| 03-Feb-2022 |
Dmitry Kozlyuk <dkozlyuk@nvidia.com> |
mem: add dirty malloc element support
EAL malloc layer assumed all free elements content is filled with zeros ("clean"), as opposed to uninitialized ("dirty"). This assumption was ensured in two way
mem: add dirty malloc element support
EAL malloc layer assumed all free elements content is filled with zeros ("clean"), as opposed to uninitialized ("dirty"). This assumption was ensured in two ways: 1. EAL memalloc layer always returned clean memory. 2. Freed memory was cleared before returning into the heap.
Clearing the memory can be as slow as around 14 GiB/s. To save doing so, memalloc layer is allowed to return dirty memory. Such segments being marked with RTE_MEMSEG_FLAG_DIRTY. The allocator tracks elements that contain dirty memory using the new flag in the element header. When clean memory is requested via rte_zmalloc*() and the suitable element is dirty, it is cleared on allocation. When memory is deallocated, the freed element is joined with adjacent free elements, and the dirty flag is updated:
a) If the joint element contains dirty parts, it is dirty:
dirty + freed + dirty = dirty => no need to clean freed + dirty = dirty the freed memory
Dirty parts may be large (e.g. initial allocation), so clearing them could create unpredictable slowdown.
b) If the only dirty part of the joint element is the freed memory, the joint element can be made clean:
clean + freed + clean = clean => freed memory clean + freed = clean must be cleared freed + clean = clean freed = clean
This logic naturally reproduces the old behavior and always applies in modes when EAL memalloc layer returns only clean segments.
As a result, memory is either cleared on free, as before, or it will be cleared on allocation if need be, but never twice.
Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com> Reviewed-by: Anatoly Burakov <anatoly.burakov@intel.com>
show more ...
|
#
770d41bf |
| 29-Oct-2021 |
Ilyes Ben Hamouda <ilyes.ben_hamouda@6wind.com> |
malloc: fix allocation with unknown socket ID
When using rte_malloc() from a thread which is not bound to a numa socket (the typical case is a control thread, but it can also happen on a dataplane t
malloc: fix allocation with unknown socket ID
When using rte_malloc() from a thread which is not bound to a numa socket (the typical case is a control thread, but it can also happen on a dataplane thread if its cpu affinity is on cores attached to several sockets), the used heap is the one from numa socket 0, which may not have available memory.
Fix this by selecting the first socket which has available memory.
Note: malloc_get_numa_socket() is only used from one .c file, so move it there, and remove the inline keyword.
Fixes: b94580d6887e ("malloc: avoid unknown socket id") Cc: stable@dpdk.org
Signed-off-by: Ilyes Ben Hamouda <ilyes.ben_hamouda@6wind.com> Signed-off-by: Olivier Matz <olivier.matz@6wind.com> Acked-by: David Marchand <david.marchand@redhat.com>
show more ...
|
#
6cc51b12 |
| 20-Oct-2021 |
Zhihong Peng <zhihongx.peng@intel.com> |
mem: instrument allocator for ASan
This patch adds necessary hooks in the memory allocator for ASan.
This feature is currently available in DPDK only on Linux x86_64. If other OS/architectures want
mem: instrument allocator for ASan
This patch adds necessary hooks in the memory allocator for ASan.
This feature is currently available in DPDK only on Linux x86_64. If other OS/architectures want to support it, ASAN_SHADOW_OFFSET must be defined and RTE_MALLOC_ASAN must be set accordingly in meson.
Signed-off-by: Xueqin Lin <xueqin.lin@intel.com> Signed-off-by: Zhihong Peng <zhihongx.peng@intel.com> Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
show more ...
|
#
99a2dd95 |
| 20-Apr-2021 |
Bruce Richardson <bruce.richardson@intel.com> |
lib: remove librte_ prefix from directory names
There is no reason for the DPDK libraries to all have 'librte_' prefix on the directory names. This prefix makes the directory names longer and also m
lib: remove librte_ prefix from directory names
There is no reason for the DPDK libraries to all have 'librte_' prefix on the directory names. This prefix makes the directory names longer and also makes it awkward to add features referring to individual libraries in the build - should the lib names be specified with or without the prefix. Therefore, we can just remove the library prefix and use the library's unique name as the directory name, i.e. 'eal' rather than 'librte_eal'
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
show more ...
|