On Tue, Apr 15, 2014 at 03:50:58PM +0200, David Marchand wrote: > From: Didier Pallard <didier.pallard at 6wind.com> > > a write memory barrier is needed before changing heap state > value, else some concurrent core may see state changing before > all initialization values are written to memory, causing > unpredictable results in malloc function. > > Signed-off-by: Didier Pallard <didier.pallard at 6wind.com> > --- > lib/librte_malloc/malloc_heap.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/librte_malloc/malloc_heap.c b/lib/librte_malloc/malloc_heap.c > index f4a0294..64668cb 100644 > --- a/lib/librte_malloc/malloc_heap.c > +++ b/lib/librte_malloc/malloc_heap.c > @@ -147,6 +147,7 @@ malloc_heap_init(struct malloc_heap *heap) > */ > heap->numa_socket = heap - mcfg->malloc_heaps; > rte_spinlock_init(&heap->lock); > + rte_wmb(); > heap->initialised = INITIALISED; > } > } > -- > 1.7.10.4 > > This certainly won't hurt anything, but from my read we have a fixed array of malloc_heaps in the mem_config array. It would seem to me that the more appropriate solution would be to initalize all of the malloc_heaps before starting any additional threads or processes that access the dpdk. I.e. call malloc_heap_init for every entry in the array during rte_eal_init. That prevents you from even needing to keep the ->initalized member around because its ready during the library initalization
Neil
