[dpdk-dev] [PATCH 1/2] mem: add write memory barrier before changing heap state
Neil Horman
nhorman at tuxdriver.com
Tue Apr 15 16:44:40 CEST 2014
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
More information about the dev
mailing list