Hi Bruce
I knew little about DPDK's milestone
I read some hints from http://dpdk.org/dev/roadmap
18.02
* Proposal deadline: November 24, 2017
* Integration deadline: January 5, 2018
I wonder whether I need to resend the patchset(the 2nd part) again after
November 24?
Thanks for any suggestions
Cheers,
Jia
On 11/8/2017 11:11 PM, Jia He Wrote:
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.
Cheers,
Jia
