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

[Thomas Monjalon <thomas@monjalon.net>]

14/10/2024 17:19, Stephen Hemminger:
> On Mon, 14 Oct 2024 08:51:09 +0200
> Mattias Rönnblom <hofors@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.