Re: [PATCH 1/2] ixgbe: fix setup of mbuf initializer template

[Jean-Mickael Guerin <jean-mickael.guerin-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>]

On 04/12/2014 15:42, Ananyev, Konstantin wrote:
>
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.org] On Behalf Of Bruce Richardson
>> Sent: Thursday, December 04, 2014 2:40 PM
>> To: Jean-Mickael Guerin
>> Cc: dev-VfR2kkLFssw@public.gmane.org
>> Subject: Re: [dpdk-dev] [PATCH 1/2] ixgbe: fix setup of mbuf initializer template
>>
>> On Thu, Dec 04, 2014 at 03:26:20PM +0100, Jean-Mickael Guerin wrote:
>>> Add a compiler barrier to make sure all fields covered by
>>> the marker rearm_data are assigned before the read.
>>>
>>> Signed-off-by: Jean-Mickael Guerin <jean-mickael.guerin-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
>>> Acked-by: David Marchand <david.marchand-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
>>> Fixes: 0ff3324da2 ("ixgbe: rework vector pmd following mbuf changes")
>>
>> Acked-by: Bruce Richardson <bruce.richardson-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>>
>>> ---
>>>   lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
>>> index 579bc46..c1b5a78 100644
>>> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
>>> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
>>> @@ -739,6 +739,9 @@ ixgbe_rxq_vec_setup(struct igb_rx_queue *rxq)
>>>   	mb_def.buf_len = rxq->mb_pool->elt_size - sizeof(struct rte_mbuf);
>>>   	mb_def.port = rxq->port_id;
>>>   	rte_mbuf_refcnt_set(&mb_def, 1);
>>> +
>>> +	/* prevent compiler reordering: rearm_data covers previous fields */
>>> +	rte_compiler_barrier();
>>>   	rxq->mbuf_initializer = *((uint64_t *)&mb_def.rearm_data);
>>>   	return 0;
>>>   }
>>> --
>
> Hmm, can someone explain to me why do we need a compiler barrier here?
> Konstantin

rearm_data is a separate field and as well an array of length zero, 
overlapping on purpose the fields data_off buf_len, port, refcnt.
It might depend on compiler, but I could see a wrong value of 0UL for 
mbuf_initializer without the barrier (gcc 4.4.6).


>
>>> 2.1.3
>>>