On Mon, 14 Oct 2024 08:51:09 +0200 Mattias Rönnblom <hof...@lysator.liu.se> wrote:
> 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? In practice, calling rte_eal_init() is not tested, and some of the drivers probably won't work.
