On 2024-10-11 10:04, Mattias Rönnblom wrote:
On 2024-10-10 23:24, Thomas Monjalon wrote:
<snip>
+ *
+ * An lcore variable is not tied to the owning thread's lifetime. It's
+ * available for use by any thread immediately after having been
+ * allocated, and continues to be available throughout the lifetime of
+ * the EAL.
+ *
+ * Lcore variables cannot and need not be freed.
I'm curious about that.
If EAL is closed, and the application continues its life,
then we want all this memory to be cleaned as well.
Do you know rte_eal_cleanup()?
I think the primary reason you would like to free the buffers is to
avoid false positives from tools like valgrind memcheck (if anyone
managed to get that working with DPDK).
rte_eal_cleanup() freeing the buffers and resetting the offset would
make sense. That however would require the buffers to be tracked (e.g.,
as a linked list).
I had a quick look at this. Cleaning up the lcore var buffers is very
straightforward.
One thing though: the rte_eal_cleanup() documentation says "After this
call, no DPDK function calls may be made.". rte_eal_init() is a "DPDK
function call". So DPDK/EAL can never be re-initialized, correct?
Cleaning up lcore var buffers would further cement this design, since
there will be no way to re-initialize them other than changing the
<rte_lcore_var.h> API.
From a footprint point of view, TLS allocations and static arrays also
aren't freed by rte_eal_cleanup().
<snip>
