Re: [dpdk-dev] [PATCH v4 0/4] fix race condition in enqueue/dequeue because of cpu reorder

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

> -----Original Message-----
> From: Jia He [mailto:hejianet@gmail.com]
> Sent: Wednesday, November 8, 2017 3:12 PM
> To: Richardson, Bruce <bruce.richardson@intel.com>
> Cc: jerin.jacob@caviumnetworks.com; dev@dpdk.org; olivier.matz@6wind.com; Ananyev, Konstantin <konstantin.ananyev@intel.com>;
> jianbo.liu@arm.com; hemant.agrawal@nxp.com
> Subject: Re: [PATCH v4 0/4] fix race condition in enqueue/dequeue because of cpu reorder
> 
> Hi Bruce
> 
> 
> On 11/8/2017 8:15 PM, Bruce Richardson Wrote:
> > On Wed, Nov 08, 2017 at 09:54:37AM +0000, Jia He wrote:
> >> We watched a rte panic of mbuf_autotest in our qualcomm arm64 server
> >> due to a possible race condition.
> >>
> >> To fix this race, there are 2 options as suggested by Jerin: 1. use
> >> rte_smp_rmb 2. use load_acquire/store_release(refer to [2]).
> >> CONFIG_RTE_RING_USE_C11_MEM_MODEL is provided, and by default it is
> >> "y" only on arm64 so far.
> >>
> >> The reason why providing 2 options is due to the performance benchmark
> >> difference in different arm machines.
> >>
> >> Already fuctionally tested on the machines as follows: - on X86 - on
> >> arm64 with CONFIG_RTE_RING_USE_C11_MEM_MODEL=y - on arm64 with
> >> CONFIG_RTE_RING_USE_C11_MEM_MODEL=n
> >>
> >> --- Changelog: V4: split into small patches V3: arch specific
> >> implementation for enqueue/dequeue barrier V2: let users choose
> >> whether using load_acquire/store_release V1: rte_smp_rmb() between 2
> >> loads
> >>
> >> Jia He (4): eal/arm64: remove the braces {} for dmb() and dsb() ring:
> >> guarantee load/load order in enqueue and dequeue ring: introduce new
> >> header file to include common functions ring: introduce new header
> >> file to support C11 memory model
> >>
> > I'm wondering what the merge plans are for this set, given we are now
> > past RC3 in 17.11? As the rings are broken on ARM machines we need to
> > merge in some fix, but I'm a little concerned about the scope of the
> > changes from the 3rd and 4th patches. Would it be acceptable to just
> > merge in patches 1 & 2 in 17.11 and leave the rework and C11 memory
> > model additions in patches 3 & 4 to 18.02 release?
> As far as I'm concerned, it is ok.

Sounds good to me too.
Konstantin