14/10/2024 17:19, Stephen Hemminger: > 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.
Yes it is not tested, I have no idea whether restarting DPDK works or not.
