From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 25A4B1B33F for ; Wed, 8 Nov 2017 13:15:56 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2017 04:15:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,364,1505804400"; d="scan'208";a="1241430681" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.32]) by fmsmga002.fm.intel.com with SMTP; 08 Nov 2017 04:15:52 -0800 Received: by (sSMTP sendmail emulation); Wed, 08 Nov 2017 12:15:52 +0000 Date: Wed, 8 Nov 2017 12:15:51 +0000 From: Bruce Richardson To: Jia He Cc: jerin.jacob@caviumnetworks.com, dev@dpdk.org, olivier.matz@6wind.com, konstantin.ananyev@intel.com, jianbo.liu@arm.com, hemant.agrawal@nxp.com Message-ID: <20171108121550.GA9632@bricha3-MOBL3.ger.corp.intel.com> References: <1510118764-29697-1-git-send-email-hejianet@gmail.com> <1510134881-22987-1-git-send-email-hejianet@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1510134881-22987-1-git-send-email-hejianet@gmail.com> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.9.1 (2017-09-22) Subject: Re: [dpdk-dev] [PATCH v4 0/4] fix race condition in enqueue/dequeue because of cpu reorder X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 12:15:57 -0000 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? Regards, /Bruce