[PATCH v9 1/7] eal: add static per-lcore memory allocation facility

[Mattias Rönnblom]

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>