From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id CEDC4A05D3 for ; Thu, 28 Mar 2019 01:22:02 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A910258C6; Thu, 28 Mar 2019 01:22:01 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 818714CBD; Thu, 28 Mar 2019 01:22:00 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1CC1F21FCF; Wed, 27 Mar 2019 20:22:00 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 27 Mar 2019 20:22:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=gGgfVhxSRqpvQRpxQX9U6l81HCRK1OxnSmkDHaPd4kg=; b=XKIO7CiCfOBr Ag2X2AQXOgNCfI0KEcgsswkADmmq/8l2F3kgVE8Npayi3NiFa/5FD2bzKwQcwd9E pope4eML17CT5xf2kwSVxoatSaFbSc6O2+9UxImzj74O/txggzmLNRRC43FS+KZu 9GVTOAZbUJuCqpR0hI2nnGVJmH8W8yA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=gGgfVhxSRqpvQRpxQX9U6l81HCRK1OxnSmkDHaPd4 kg=; b=vE4kFAu7idBm2+owT/Em5dc1/vsYRr6YTC9p+4pxxGyFx8/Z7zvvK22rg slZ+pFqPVv9e6DOL8bmlE/q8xgaY8zGE8i1HyzDkTQYHR7xRpj9QLapVbURkH9b/ dka+pnHs1a73F7FJoESbtB0aCRebnfbTkDdQ+iodS8sBwraddRJVq4YIYx2We1/8 G5HPSkXdIhQiGBkOl2GJhy4yMY13eAOd6CKFfcLnhpU+JbslB/TPeVGzk1HYgDfl d9lefbshokPE3uMzby5ZT39ypYdCZRFccwehHnx1AdyouwHZo4W+wQtmg8sPeAvK VJ0iaiZV8t67qgjDeX0Byap1NPt9A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkeefgdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinheptggrmhdrrggtrdhukhenucfkphepjeejrddufeegrddvtdefrddukeegnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id B9128100E5; Wed, 27 Mar 2019 20:21:56 -0400 (EDT) From: Thomas Monjalon To: Gavin Hu Cc: dev@dpdk.org, "Ananyev, Konstantin" , "nd@arm.com" , "jerinj@marvell.com" , "hemant.agrawal@nxp.com" , "nipun.gupta@nxp.com" , "Honnappa.Nagarahalli@arm.com" , "i.maximets@samsung.com" , "chaozhu@linux.vnet.ibm.com" , "stable@dpdk.org" Date: Thu, 28 Mar 2019 01:21:55 +0100 Message-ID: <1963883.zIr16fWVUr@xps> In-Reply-To: <2601191342CEEE43887BDE71AB977258013655C014@irsmsx105.ger.corp.intel.com> References: <1551841661-42892-1-git-send-email-gavin.hu@arm.com> <1552409933-45684-2-git-send-email-gavin.hu@arm.com> <2601191342CEEE43887BDE71AB977258013655C014@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v3 1/1] ring: enforce reading the tail before reading ring slots 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190328002155.OwO7dVpeGBZV_jPmvYbbu5SPmdndka7g6NVTBCAWm5o@z> > > In weak memory models, like arm64, reading the prod.tail may get > > reordered after reading the ring slots, which corrupts the ring and > > stale data is observed. > > > > This issue was reported by NXP on 8-A72 DPAA2 board. The problem is most > > likely caused by missing the acquire semantics when reading > > prod.tail (in SC dequeue) which makes it possible to read a > > stale value from the ring slots. > > > > For MP (and MC) case, rte_atomic32_cmpset() already provides the required > > ordering. For SP case, the control depependency between if-statement(which > > depends on the read of r->cons.tail) and the later stores to the ring slots > > make RMB unnecessary. About the control dependency, read more at: > > https://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf > > > > This patch is adding the required read barrier to prevent reading the ring > > slots get reordered before reading prod.tail for SC case. > > > > Fixes: c9fb3c62896f ("ring: move code in a new header file") > > Cc: stable@dpdk.org > > > > Signed-off-by: gavin hu > > Reviewed-by: Ola Liljedahl > > Tested-by: Nipun Gupta > > Acked-by: Konstantin Ananyev Applied, thanks