[Internet]Re: [PATCH v3] acl: support custom memory allocator

[mannywang(王永峰)]

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(王永峰)" <mannywang at tencent.com> 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 <mannywang at tencent.com>
>> ---
> 
> 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
> 
>