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?
