From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com [210.118.77.12]) by dpdk.org (Postfix) with ESMTP id 2089B4F9B for ; Wed, 6 Mar 2019 12:49:08 +0100 (CET) Received: from eucas1p1.samsung.com (unknown [182.198.249.206]) by mailout2.w1.samsung.com (KnoxPortal) with ESMTP id 20190306114907euoutp02a59bdd8ecc3b58afd20882ca22e71f12~JXDlMMmBY1791817918euoutp02Y for ; Wed, 6 Mar 2019 11:49:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.w1.samsung.com 20190306114907euoutp02a59bdd8ecc3b58afd20882ca22e71f12~JXDlMMmBY1791817918euoutp02Y DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1551872947; bh=vDOwKV3v/ggxARQomFwKOE90NFvm7stLKftojpvT45o=; h=Subject:To:Cc:From:Date:In-Reply-To:References:From; b=IWLKvT7lAN31bB/+I4jFWVdtTFsu2/60lWmMiqKWZG/8qNllq1VWQopCGYKKDkG6o MdMzjHwSWafuzuecCFdUTtyc0y+Px/m0t82yuktPhd18bgREAHYSjR836Ni0Po98es gOwsHJ+1o+r0TzTaa2Qo473SR8vV1+3gSK9SUuO0= Received: from eusmges1new.samsung.com (unknown [203.254.199.242]) by eucas1p2.samsung.com (KnoxPortal) with ESMTP id 20190306114907eucas1p2dfda1a8e98c75a4904b85f2e499844f0~JXDkuDLWJ0050600506eucas1p2O; Wed, 6 Mar 2019 11:49:07 +0000 (GMT) Received: from eucas1p1.samsung.com ( [182.198.249.206]) by eusmges1new.samsung.com (EUCPMTA) with SMTP id EF.2A.04441.2B3BF7C5; Wed, 6 Mar 2019 11:49:06 +0000 (GMT) Received: from eusmtrp2.samsung.com (unknown [182.198.249.139]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20190306114906eucas1p19c2572b1fe777e1eb0ca96d2e47295bd~JXDj8PGx82866128661eucas1p1h; Wed, 6 Mar 2019 11:49:06 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eusmtrp2.samsung.com (KnoxPortal) with ESMTP id 20190306114906eusmtrp2325585b7786f03beea16a6e2e868816d~JXDjtnNxh1625316253eusmtrp2y; Wed, 6 Mar 2019 11:49:06 +0000 (GMT) X-AuditID: cbfec7f2-5c9ff70000001159-fe-5c7fb3b2aac0 Received: from eusmtip1.samsung.com ( [203.254.199.221]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id 4E.29.04284.2B3BF7C5; Wed, 6 Mar 2019 11:49:06 +0000 (GMT) Received: from [106.109.129.180] (unknown [106.109.129.180]) by eusmtip1.samsung.com (KnoxPortal) with ESMTPA id 20190306114905eusmtip1bfc8e560fcba76df2c334f58e52103f8~JXDjFq64V0072600726eusmtip1D; Wed, 6 Mar 2019 11:49:05 +0000 (GMT) To: gavin hu , dev@dpdk.org Cc: nd@arm.com, thomas@monjalon.net, jerinj@marvell.com, hemant.agrawal@nxp.com, nipun.gupta@nxp.com, Honnappa.Nagarahalli@arm.com, olivier.matz@6wind.com From: Ilya Maximets Message-ID: <572899c3-f7cd-77a9-8f60-50e117967678@samsung.com> Date: Wed, 6 Mar 2019 14:49:04 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <1551841661-42892-1-git-send-email-gavin.hu@arm.com> Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA02SbyxVcRjH+51z7j3n3rk6LrnPaGvuvMj/jNp5gbK13BfZeilZuronFJfu RWjryoQZpWy4ivTC5F8N1/Vva67y325IQzX/QpHL/GkLTXUclnefPd/v8/09z7MfhUtNAgcq Wp3AatTKGLlQTBi7t8weDY26sFOmUYZZWW/GmL7vS4ip+lovZPTzGSQzmrVFMnnvnyJmsDIX Z8w9A4hpSq/HmPXpXuKcWDH86AtS1JbVIsV2eYVAUfBiGFd0TxSSivqVFkzx0FCNLpGhYj8V GxOdxGq8Aq6Joz63NqL4GZvkqfY0Ig2lW+cgEQW0L+iH9MIcJKak9EsExpFljBOk9CaCuVx3 XthAMPrGjB905JsKBbypEkFV/WXetIbgW5pJyAm2tAIKhh6THNvRHrCW2bTXjNNlCFrvB3Es pN2hv+Yd4lhCB0BRdQeRgyiKoJ1hayyZKx+jQ2B1vp3gLTbQp5/bYxEdCJaCEZKPlEH6ZpWA 5xPQbHmGc/MA/YmEaUOugMsE+jwMLETw89vCUo+B5Pk4/Gl9jvGsg6mMRcT3ZiMo6tzdF86C 4YeZ5HJw2gVet3nx5UCY/fAL4+OtYdxiw49gDU+MRThflkB2ppR3O8OOqXL/gg4wsbJB5iN5 yaHFSg4tU3JomZL/75YjohrJ2ERtbCSr9Vazdzy1ylhtojrS83pcbAP697EGdnvWW9DPkYhO RFNIbiXJf3AvTCpQJmlTYjsRULjcThJUqwuTSlTKlFRWExeuSYxhtZ3IkSLkMsndI9NXpHSk MoG9xbLxrOZAxSiRQxoKk83fdvGvueGsMllNjS93Nbt5BHQNHvXN2gk4s+jkWmau23g1O+my XCowrPpNRKpEuSn5xovLtclv2zAf+8mPIZUVmxnBk4teYzOO234DwaETWLiTro6xder9bVFm uHnfFGlWOvTFCz6pxZmy0xdO+loCrwap+3WlCfZ5a/5rckIbpfR2xTVa5V+ZOpY5VAMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsVy+t/xu7qbNtfHGPx8w27x7tN2JouTL14x Wqx8vJHNYubTFnaLK+0/2S16z89mtDizvIfZ4tzx04wWW5s2Mll8enCCxYHL42L/HUaPNfPW MHr8WrCU1WPywovMHsduTmP32PhuB5NH35ZVjAHsUXo2RfmlJakKGfnFJbZK0YYWRnqGlhZ6 RiaWeobG5rFWRqZK+nY2Kak5mWWpRfp2CXoZt3duZix4KFhxf3cDSwNjE18XIyeHhICJxISD 01i7GLk4hASWMkrMuPuQHSIhJfHj1wVWCFtY4s+1LjaIoveMEhuPXwRLCAt4SEy+MBGsQURA V+Jj21ZmkCJmgXmMEjc3TWLqYuQA6nCQ6JySB1LDJqAjcWr1EUYQm1fATmL6qgMsICUsAioS P69XgIRFBSIk7l58wQJRIihxcuYTMJtTwFHi7eRLYKuYBdQl/sy7xAxhi0s0fVnJCmHLS2x/ O4d5AqPQLCTts5C0zELSMgtJywJGllWMIqmlxbnpucWGesWJucWleel6yfm5mxiBcbrt2M/N OxgvbQw+xCjAwajEwzuhtS5GiDWxrLgy9xCjBAezkgiv+5r6GCHelMTKqtSi/Pii0pzU4kOM pkC/TWSWEk3OB6aQvJJ4Q1NDcwtLQ3Njc2MzCyVx3vMGlVFCAumJJanZqakFqUUwfUwcnFIN jE7V+QtX+Mg51p9W+nKxuXbv1d0t/eam3XHqF97pyM1nUL+1SrMwwj9aP//d5dXh6udvCd6e 5lMS7rJc//omBrFJvl1XUqNb56Vp5t3pdn3pUpQeW/1m+mUmkTD5oqlW8Zka1tYliRPMw3fb Nymt2iuwZZ7Ekfv+JwpfbYoOXxrznlV2ludWJZbijERDLeai4kQA6jqjZ+kCAAA= X-CMS-MailID: 20190306114906eucas1p19c2572b1fe777e1eb0ca96d2e47295bd X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20190306114906eucas1p19c2572b1fe777e1eb0ca96d2e47295bd X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20190306114906eucas1p19c2572b1fe777e1eb0ca96d2e47295bd References: <1551841661-42892-1-git-send-email-gavin.hu@arm.com> Subject: Re: [dpdk-dev] [v1] ring: enforce reading the tails before ring operations 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, 06 Mar 2019 11:49:09 -0000 On 06.03.2019 6:07, gavin hu wrote: > In weak memory models, like arm64, reading the {prod,cons}.tail may get > reordered after reading or writing 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 cons.tail (in > SP enqueue) or prod.tail (in SC dequeue) which makes it possible to read a > stale value from the ring slots. There must be a read fence before writing Sorry, but the phrase "There must be a read fence before writing" makes no sense. Could you please rephrase or describe in details which reads you're trying to keep in exact order? > or reading the ring slots, rte_atomic32_cmpset() provides the same ordering > for MP (and MC) case. This patch is to enforce this ordering for SP (and > SC) case. > > Signed-off-by: gavin hu > Reviewed-by: Ola Liljedahl > Tested-by: Nipun Gupta > --- > lib/librte_ring/rte_ring_generic.h | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/lib/librte_ring/rte_ring_generic.h b/lib/librte_ring/rte_ring_generic.h > index ea7dbe5..1bd3dfd 100644 > --- a/lib/librte_ring/rte_ring_generic.h > +++ b/lib/librte_ring/rte_ring_generic.h > @@ -90,9 +90,11 @@ __rte_ring_move_prod_head(struct rte_ring *r, unsigned int is_sp, > return 0; > > *new_head = *old_head + n; > - if (is_sp) > - r->prod.head = *new_head, success = 1; > - else > + if (is_sp) { > + r->prod.head = *new_head; > + rte_smp_rmb(); > + success = 1; > + } else > success = rte_atomic32_cmpset(&r->prod.head, > *old_head, *new_head); > } while (unlikely(success == 0)); > @@ -158,9 +160,11 @@ __rte_ring_move_cons_head(struct rte_ring *r, unsigned int is_sc, > return 0; > > *new_head = *old_head + n; > - if (is_sc) > - r->cons.head = *new_head, success = 1; > - else > + if (is_sc) { > + r->cons.head = *new_head; > + rte_smp_rmb(); > + success = 1; > + } else > success = rte_atomic32_cmpset(&r->cons.head, *old_head, > *new_head); > } while (unlikely(success == 0)); >