From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jia He Subject: Re: [PATCH v4 0/4] fix race condition in enqueue/dequeue because of cpu reorder Date: Fri, 24 Nov 2017 10:08:18 +0800 Message-ID: <2459a535-920e-9ac5-2f46-1d1dd00e275b@gmail.com> References: <1510118764-29697-1-git-send-email-hejianet@gmail.com> <1510134881-22987-1-git-send-email-hejianet@gmail.com> <20171108121550.GA9632@bricha3-MOBL3.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, olivier.matz@6wind.com To: Bruce Richardson Return-path: Received: from mail-pl0-f50.google.com (mail-pl0-f50.google.com [209.85.160.50]) by dpdk.org (Postfix) with ESMTP id 86E34223 for ; Fri, 24 Nov 2017 03:08:27 +0100 (CET) Received: by mail-pl0-f50.google.com with SMTP id h3so3554125pln.10 for ; Thu, 23 Nov 2017 18:08:27 -0800 (PST) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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