Hi,
I suppose you mean some sort of user-provided
alloc()/free() callbacks that
will be used by ACL lib at generate phase?
And I presume if none provided, by default it will
fall-back to rte_malloc/rte_free?
If so, then yes, sounds reasonable.
Patches are welcomed :)
Konstantin
From: mannywang(王永峰)
<mannywang@tencent.com>
Sent: Friday, November 14, 2025 2:52 AM
To: dev <dev@dpdk.org>
Cc: konstantin.v.ananyev <konstantin.v.ananyev@yandex.ru>
Subject: [RFC] rte_acl_build memory fragmentation concern and proposal for external memory support
Hello DPDK community,
We've been using DPDK's ACL library in a long-running network application
and observed a concerning issue regarding memory fragmentation. The rte_acl_build()function
internally uses rte_zmalloc_socket()for
dynamic memory allocation during ACL rule compilation.
While this design works well for short-lived processes, it creates challenges
for long-running applications (days/weeks) where memory fragmentation becomes a critical concern. Each ACL rebuild (due to rule updates, configuration changes, etc.) allocates variable-sized memory blocks for the trie structures and transition tables, which
are then freed when the ACL context is destroyed or rebuilt.
This pattern leads to:
1. Memory
fragmentation over time, as
the heap accumulates "holes" of varying sizes
2. Potential
allocation failures even when
total free memory appears sufficient
3. Difficulty
in memory budgeting for deterministic
systems
The current API doesn't allow applications to provide pre-allocated
memory for ACL construction, forcing dynamic allocations that contribute to heap fragmentation. This is particularly problematic for applications that prioritize long-term stability and predictable memory usage.
We propose extending the ACL API to support external memory buffers
for the build process. This would allow applications to manage memory allocation strategies according to their specific requirements (pool-based, static allocation, etc.).