Please forgive me for repeating myself, because I am worried that I did
not express it clearly:
ACL does not need a memory manager, because for each build it only
allocates one block of memory, and before the next build (during reset)
the memory is freed. The temporary memory is slightly more complicated
since it is allocated multiple times, but it is still freed all at once.
Therefore, for ACL, we do need to allocate memory, but we do not need a
memory manager.
However, the memory used in the current build process is indeed
dynamically allocated, which will cause fragmentation in the
corresponding memory manager when multiple builds are performed.
Based on the above situation, I think the most reasonable approach is to
bind a pre-allocated static memory block to the ACL context.
On 12/11/2025 9:46 AM, Stephen Hemminger wrote:
On Tue, 25 Nov 2025 12:14:46 +0000
"mannywang(王永峰)" <[email protected]> wrote:
Reduce memory fragmentation caused by dynamic memory allocations
by allowing users to provide custom memory allocator.
Add new members to struct rte_acl_config to allow passing custom
allocator callbacks to rte_acl_build:
- running_alloc: allocator callback for run-time internal memory
- running_free: free callback for run-time internal memory
- running_ctx: user-defined context passed to running_alloc/free
- temp_alloc: allocator callback for temporary memory during ACL build
- temp_reset: reset callback for temporary allocator
- temp_ctx: user-defined context passed to temp_alloc/reset
These callbacks allow users to provide their own memory pools or
allocators for both persistent runtime structures and temporary
build-time data.
A typical approach is to pre-allocate a static memory region
for rte_acl_ctx, and to provide a global temporary memory manager
that supports multipleallocations and a single reset during ACL build.
Since tb_mem_pool handles allocation failures using siglongjmp,
temp_alloc follows the same approach for failure handling.
Signed-off-by: YongFeng Wang <[email protected]>
---
Rather than custom allocators, I did a couple of quick AI queries about
alternatives. It looks like there are some big global gains possible
here:
Summary of Recommendations
Improvement Benefit Complexity Priority
ACL Object Pooling Eliminates ACL-specific fragmentation Medium High
Size-Class Segregation Reduces general fragmentation High High
Slab Allocator for Build Better hugepage utilization Medium Medium
Deferred Coalescing Reduces fragmentation from churn Medium Medium
Thread-Local Caching Reduces contention, improves locality Medium Medium
Also adding some malloc_trim() would help.
https://claude.ai/share/75fcf73c-17e3-4f41-8590-f2ab640f9512
