[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