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

[Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>]

On 11/26/25 05:44, mannywang(王永峰) wrote:
> Thanks for sharing this suggestion.
>
> We actually evaluated the heap-based approach before implementing this 
> patch.
> It can help in some scenarios, but unfortunately it does not fully 
> solve our
> use cases. Specifically:
>
> 1. **Heap count / scalability**
>    Our application maintains at least ~200 rte_acl_ctx instances (due 
> to the
>    total rule count and multi-tenant isolation). Allowing a dedicated 
> heap per
>    context would exceed the practical limits of the current rte_malloc 
> heap
>    model. The number of heaps that can be created is not unlimited, and
>    maintaining hundreds of separate heaps would introduce considerable
>    management overhead.
This is a valid point against heaps, thanks.
> 2. **Temporary allocations in build stage**
>    During `rte_acl_build`, a significant portion of memory is 
> allocated through
>    `calloc()` for internal temporary structures. These allocations are 
> freed
>    right after the build completes. Even if runtime memory could come 
> from a
>    custom heap, these temporary allocations would still need an 
> independent
>    allocator or callback mechanism to avoid fragmentation and repeated
>    malloc/free cycles.
I don't understand the build stage issue and why it needs a custom 
allocator.
What exactly gets fragmented?
It is the entire process address space which is practically unlimited?
How does is malloc/free overhead compare to the overall ACL build time?