From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0063.outbound.protection.outlook.com [104.47.34.63]) by dpdk.org (Postfix) with ESMTP id F18451B67D for ; Fri, 3 Nov 2017 13:56:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kulmVqjWv6+1ku8CM8HNuwc9uvYWzaE7JPmpDXsLAYw=; b=XYfrZEUVJLEZS1Ze+ywex+fFTFkm9KC6OzmLIgXJfNDJcLkGXao1UUzuZks2QEAEbaMSWjW4WPAJ3kVbCOY0PELkn7ts6bwFueyswtOAMtd9SugxMUju323gfsZLluxFBqTJ8BoqTNVx8DhvkXSQyny/EhmAZ0jyBHfmd2RfEQM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (171.76.99.7) by CO2PR07MB2517.namprd07.prod.outlook.com (10.166.200.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Fri, 3 Nov 2017 12:56:33 +0000 Date: Fri, 3 Nov 2017 18:26:17 +0530 From: Jerin Jacob To: Jia He Cc: dev@dpdk.org, olivier.matz@6wind.com, konstantin.ananyev@intel.com, bruce.richardson@intel.com, jianbo.liu@arm.com, hemant.agrawal@nxp.com, jie2.liu@hxt-semitech.com, bing.zhao@hxt-semitech.com, jia.he@hxt-semitech.com Message-ID: <20171103125616.GB20326@jerin> References: <1509612210-5499-1-git-send-email-hejianet@gmail.com> <20171102172337.GB1478@jerin> <25192429-8369-ac3d-44b0-c1b1d7182ef0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25192429-8369-ac3d-44b0-c1b1d7182ef0@gmail.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Originating-IP: [171.76.99.7] X-ClientProxiedBy: MA1PR0101CA0011.INDPRD01.PROD.OUTLOOK.COM (52.134.136.149) To CO2PR07MB2517.namprd07.prod.outlook.com (10.166.200.151) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6c46560d-affe-482d-1c99-08d522ba51a9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CO2PR07MB2517; X-Microsoft-Exchange-Diagnostics: 1; CO2PR07MB2517; 3:hxT5RdgI52QTCU2o8FvBLjo+zvJUcDtfySnGz72aMFEglql8a3VIIki6xfjpNm0JLjh/b6jnekKD65+63U6CyVmomi3HVPuxuktIzD38bDgkTbHz1CoxKVEcAfsCkMPGNuD42IY4e9G3LewFyVNz6UOqpZhnLMNA4xZbmhbNYD1U+367ZwVrxQ7AHvcpAYUZmNOXaAloBMGtDnENAHW+wT07uUWULXJcyQFbez/ehJ0zYarJzufzYvpCnYndW6w6; 25:oBuY6pufwr4Lfo2EJuN0a2h1ha864Z2/bGZkLdBKVq16b0yYM6acnG5jUN95KR0teIbdRayi3cUCyjDOCXDjHxFs0vlXiVaqCTc+743q/TvA3QKk4Izm2vv99X4H7EtfoohDJPduYzhesxXOU9crsArpaC5VGu93WrVa54HdL57uNnS+Cfy/2P+mElWCpd6L84BFgpplsoxa9TzRUFunRaYD3gFw5L3I4WiwqpFdQA7bFPGiRpiODODVrB3iS6C7J4tQGKcL00uIgI9O1+JlnEgWJhrvCoPS5cY+o1pfRefAwLkaqc9anIizSbXSTkvtbRswUbXem1gAiqrFinugnA==; 31:iZlTZ/VkafaueVJLRl8BeTTlGQoYbjw/5m+ndVmL/GoqN/nMOAqK6G74tAaZWS+YaqVVCnXPOXsXv2h2afpRm0xlotU0CIpWKfEF/Lv4muT0Q7A981HQlGV0JBqJCPCqSPyoJguZi6Ns8hOR5GRI2od/OnyeuxdAlgc716rvOEQKRHFaoqz9BDjqNmBsgqaiSzDb6IF3LHVbiJ8mImVsDIC914O+er9ylluY+AF/kPI= X-MS-TrafficTypeDiagnostic: CO2PR07MB2517: X-Microsoft-Exchange-Diagnostics: 1; CO2PR07MB2517; 20:778ovloMb7J+OjUaC9Xd/AMM7pFqNFSXcsnaCHjQwxDpSRk8b0r1jmAXRjqzuP87oC97g6IAyxJDRcvLAcMLkPZnljNWTpFkT0MVYH+WKw5GOCSLCkZsr4hQNi4xkQM6I/4JM2gZV/aKuttsgnBk6NLblHOR+kngHRGw/vmWXnvmqnf6LHGMaZEOBSTP9MjCUrrGyrS7UCOQBXIx1xIwFPTU4N9F5TP75czLgVpGgqb6XVP461AyyF/Y93XDI6vFIV/6AS4nyvv3qZd2KV1zuQ2Vp6/zaakdrpym7MtvXrSh6cLYYXgQgHbil/WXXrsGd+kjTzXWgoQjxg5KncpLarYNP6ZlyHwX3WsjfS7hS0LfgQyqZKsDsxNmlLgUpDRxdjlP/JZWj7E3uZe6U0UF1Q4XhpG2yOzoIslQXnj6XI3RJ4sZTWZCxfY2ShwrjkMSJ6l2n68IZPr/Rztc3PrVdAdGNN/NRVJqTBXvDQE6pwxuw3mQafmoCNKNqEwC41F1jguiHNiQ3ZA5mFtD7QxZnCEIEIVfq4US+mAf30wwIB6EuTFC0uFQ+9ASaYTaBTmZutXuwNrL8Z7NVNKhsMwZiY1KFZiea0D2snKSk1A5oak= X-Exchange-Antispam-Report-Test: UriScan:(180628864354917)(185117386973197)(228905959029699); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(100000703101)(100105400095)(3002001)(3231021)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CO2PR07MB2517; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO2PR07MB2517; X-Microsoft-Exchange-Diagnostics: 1; CO2PR07MB2517; 4:jrfTCxHKkJa8oM+9Ulj0R1fBmnpjWM+Alh8XSNe5J0c7iyyI06b8FhDXEcPJNtD3sGhguMC9y763NuhMyigAOIJTFJDWXfHPSuBEmRaPnt2AMsu1Wy8FxvjeykHYJwfriJ1sYp+TytC5iHsjvxSkKgcSbqnX2UP+hwA/ODR8yZJwL9retkR5yxIuBa/QonVHlbJHRrvJwUHY9gslqYmGbyylShPg1RiBoijFqc9KSHqUeWAnMHmpUdIvwByP80UNkKAIJ9nSlBdIHRW5+xj/hygj6f0GMpdHXl4oRzd+uQDqt/Q13gCVy5Bw5s2H9Xtle0b4wHcyseRcc8zb8cLOhxOwWP/ng0Ny8HkGp/B9fDCD+4+/Lm1U0+MJSXJ5J37S X-Forefront-PRVS: 0480A51D4A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(24454002)(189002)(13464003)(54534003)(33716001)(50466002)(33656002)(478600001)(54356999)(50986999)(76176999)(81156014)(8676002)(81166006)(8936002)(68736007)(25786009)(8656006)(2906002)(316002)(16586007)(58126008)(72206003)(3846002)(189998001)(6116002)(23726003)(1076002)(83506002)(4326008)(16526018)(6496005)(6246003)(106356001)(105586002)(2950100002)(305945005)(55016002)(1411001)(39060400002)(6666003)(6916009)(42882006)(101416001)(229853002)(47776003)(7416002)(53936002)(66066001)(9686003)(97736004)(5660300001)(7736002)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR07MB2517; H:jerin; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO2PR07MB2517; 23:m2bRT79XcUHlYUny7umAlgVTGE0wtVEJRPux4RNDr?= =?us-ascii?Q?LtCpGM4ChObSvK/eCZBCwMzkTAZGjFYAm0T1CuPfZK/LWSCgM8XOfrQ2l3LK?= =?us-ascii?Q?IH6pummePh+3kEGLY3iLUHrYNDZCoHCLtOHOqWxUqXw9dgyiDFguFC42BDXs?= =?us-ascii?Q?IU6p6UlVPOpA5ENcSmmdSJGV0QW9zmtNkRY4QOLFEWKHQxYpKgBkM5HBYpMN?= =?us-ascii?Q?sNWtn0aqdx2r729wpYq7ZmLtXlO70vN+DbNsfBBhVU6p8c52CstSKrchhFLK?= =?us-ascii?Q?IOF9thdF09wYNluD15J3jAC5rlt0JTvIIkvL3mC6tkeBoaKfLGUmGHMAuexM?= =?us-ascii?Q?b1JY8NKuDPdeYS6Iy/26YX0HfCbIOWp2sd4XkqW/r3Wg+7uocCmunTIxeOqk?= =?us-ascii?Q?gIksNwTsqtAI9sK4fEUD0RsXzDPqnO0QTozDr19UMhgqtAonsfG2cGgusdrF?= =?us-ascii?Q?ByVw5bJI7TV5T5eWQ4ppRZRr4iek4/cihJTmkPSPo/lMofT7sMzmF373W1Mh?= =?us-ascii?Q?eo6Hy4jmOP25sCv75bZMssx0qiskuxMJpMnHh0RPpNTzub3M1EfGZAuQ7VLO?= =?us-ascii?Q?a63ezcI6x6FtH1lNNY09rtXUSaWG2f0jxQsmrUr9iZWWYxLfLX3uLtMFBCfJ?= =?us-ascii?Q?9gnsUgL6ptwYcbPdc42SMb0Mi7FGnMCftfzHXJKVfqc5TmJ9t/K2yW0vcehu?= =?us-ascii?Q?O1gPGkuABDEBmGcfZVTKLOfY/V1mElWOFVAxFQ28adIwmo8OR87ot5200gZQ?= =?us-ascii?Q?8rVu9Md+/JQxr0Nzl3aeN+kDvcm0LfFYAbCX4sFqj4StKXj1R4s/pAVjzV3j?= =?us-ascii?Q?JBtw3QpTENQ+H5OTOyn0I/rgHiKe68o5x9AGSsgWPz4jFRyejC0FlbbagbGf?= =?us-ascii?Q?yKfV2U22V58MI1MtJ0JR9+icYbpuMBt6YL6hqVa5PR8Q+rbpPqS0JsKKIjKP?= =?us-ascii?Q?eBg6C2gpHCv1b3GccvCbg+isvAHtKU1kOXtuJ+q8lnLoz/0/6mXvyP7knOmv?= =?us-ascii?Q?x08jW5AeZY/EBkM/LBs3EeE2dIqxQqB5Qyk/uGQPeEsuBYno/4bM1lBMQ45M?= =?us-ascii?Q?AWRpJNqgoDIN+d8Ld1GeUNJWqBX1SZG6+MM+yM38areoDEhjW+2phlo7o9uU?= =?us-ascii?Q?CBVhF3XuG+oodS/yuitNVPrqm2d7X60yyoPruKC0XKaUfi6qgzIMdpi2qrkA?= =?us-ascii?Q?lsVkq1aL1wu3m80wrW3RYYoPLwhMBjNSm3mUnu5sze/H3+DtnKSXLFl6bjha?= =?us-ascii?Q?dbflnPisfbem+km5QLVdHXLdzoDqpy5flf/iS/R170eGV7gn+zZ8JY29j/gm?= =?us-ascii?Q?m8VnQ5S03QQ30uBMifUNZcazBcOp5aM3nuV/GQ9IC59?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR07MB2517; 6:Mcx/xhfyqqwIsj/snNMVy4ERpi0/23do1svaDpyy0nPV1TCqw95pW7880NZeB0mfU2eSmh97DXLBBlSeZ49f0PXVhhKDLVL7a4GehHNGz1/QzIzx++BSYN21hwBmtJU6RodcSVA0itB8WW/vd2hHeGFS3sRuay3ciZ9DgfNFK3WWxTfrkc1QaBRrWn4nKc+acBobstw3nyljRJdyFhH0JPeDAhV5KvGVV4rNRA+/hFX2LjmQ8xcGXjRvikjkQXxrbztDSAua+7WV+U+kdiPhXOJnolFGgXn99K++OEo39zem0auOe7HJeRAHawzu/gBdYteVBLHHZTRd8jOkQvBnA309yCxYdSoQye4Ed2FM7F8=; 5:iXb6ntfmIsm8KsS9IuioT9m34D5pxELraDvByGFYI/HhCp/HPYxfXC503yDxC9TshwiWIgFVf3t7QcWrcjRWyA03vcWU+x8JpBeOGkx/tYtL6yZoKUVf+gY3n14YlDYXebK8zRq53wfjI24dv0vUh8cNUG3cUUSnlB30LTvbn+s=; 24:tt47d0rQrmN3NLLvGYnGTevVW/lp85NOU+HxNAPWQb2Fv6yyyMXV1XX/nw3ewdLzK/vlW39G4BGyb3wLl4kPxcrxAiRxCf5gHQCuFgliVEg=; 7:Yt1IRpGihjZv6bDHfzxzRsWaxgduCJeJ5j8dASuZhO3+/Glt+dFi/az/Xe2rg6zGr3dKXApnnpE/pqXpLEgNKsgB76BwiBJ1Kqwtg9AF9gAtoICeiGO8RuTCWB3+Ok2CJSVlFd5IiB20/aFZx+Tl0JogxPdkVAyN6S5F8gATOjQ+UhraDt+RJDnAhYv27JHSKqILN92oObfYqWiGGs1103AjRaam2lZ3E9nxZougk8uNUIevCKwFx+ioKU7kwMWt SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2017 12:56:33.5841 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6c46560d-affe-482d-1c99-08d522ba51a9 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR07MB2517 Subject: Re: [dpdk-dev] [PATCH v2] ring: guarantee ordering of cons/prod loading when doing 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: Fri, 03 Nov 2017 12:56:40 -0000 -----Original Message----- > Date: Fri, 3 Nov 2017 09:46:40 +0800 > From: Jia He > To: Jerin Jacob > Cc: dev@dpdk.org, olivier.matz@6wind.com, konstantin.ananyev@intel.com, > bruce.richardson@intel.com, jianbo.liu@arm.com, hemant.agrawal@nxp.com, > jie2.liu@hxt-semitech.com, bing.zhao@hxt-semitech.com, > jia.he@hxt-semitech.com > Subject: Re: [PATCH v2] ring: guarantee ordering of cons/prod loading when > doing > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.4.0 > > Hi Jerin > > > On 11/3/2017 1:23 AM, Jerin Jacob Wrote: > > -----Original Message----- > > > Date: Thu, 2 Nov 2017 08:43:30 +0000 > > > From: Jia He > > > To: jerin.jacob@caviumnetworks.com, dev@dpdk.org, olivier.matz@6wind.com > > > Cc: konstantin.ananyev@intel.com, bruce.richardson@intel.com, > > > jianbo.liu@arm.com, hemant.agrawal@nxp.com, Jia He , > > > jie2.liu@hxt-semitech.com, bing.zhao@hxt-semitech.com, > > > jia.he@hxt-semitech.com > > > Subject: [PATCH v2] ring: guarantee ordering of cons/prod loading when doing > > > X-Mailer: git-send-email 2.7.4 > > > > > > We watched a rte panic of mbuf_autotest in our qualcomm arm64 server. > > > As for the possible race condition, please refer to [1]. > > Hi Jia, > > > > In addition to Konstantin comments. Please find below some review > > comments. > > > Furthermore, there are 2 options as suggested by Jerin: > > > 1. use rte_smp_rmb > > > 2. use load_acquire/store_release(refer to [2]). > > > CONFIG_RTE_ATOMIC_ACQUIRE_RELEASE_BARRIER_PREFER is provided, and by > > I think, The better name would be CONFIG_RTE_RING_USE_C11_MEM_MODEL > > or something like that. > Ok, but how to distinguish following 2 options? No clearly understood this question. For arm64 case, you can add CONFIG_RTE_RING_USE_C11_MEM_MODEL=y in config/defconfig_arm64-armv8a-* > > CONFIG_RTE_RING_USE_C11_MEM_MODEL doesn't seem to be enough > > 1. use rte_smp_rmb > 2. use load_acquire/store_release(refer to [2]). > > > > default it is n; > > > > > > --- > > > Changelog: > > > V2: let users choose whether using load_acquire/store_release > > > V1: rte_smp_rmb() between 2 loads > > > > > > Signed-off-by: Jia He > > > Signed-off-by: jie2.liu@hxt-semitech.com > > > Signed-off-by: bing.zhao@hxt-semitech.com > > > Signed-off-by: jia.he@hxt-semitech.com > > > Suggested-by: jerin.jacob@caviumnetworks.com > > > --- > > > lib/librte_ring/Makefile | 4 +++- > > > lib/librte_ring/rte_ring.h | 38 ++++++++++++++++++++++++------ > > > lib/librte_ring/rte_ring_arm64.h | 48 ++++++++++++++++++++++++++++++++++++++ > > > lib/librte_ring/rte_ring_generic.h | 45 +++++++++++++++++++++++++++++++++++ > > > 4 files changed, 127 insertions(+), 8 deletions(-) > > > create mode 100644 lib/librte_ring/rte_ring_arm64.h > > > create mode 100644 lib/librte_ring/rte_ring_generic.h > > > > > > diff --git a/lib/librte_ring/Makefile b/lib/librte_ring/Makefile > > > index e34d9d9..fa57a86 100644 > > > --- a/lib/librte_ring/Makefile > > > +++ b/lib/librte_ring/Makefile > > > @@ -45,6 +45,8 @@ LIBABIVER := 1 > > > SRCS-$(CONFIG_RTE_LIBRTE_RING) := rte_ring.c > > > # install includes > > > -SYMLINK-$(CONFIG_RTE_LIBRTE_RING)-include := rte_ring.h > > > +SYMLINK-$(CONFIG_RTE_LIBRTE_RING)-include := rte_ring.h \ > > > + rte_ring_arm64.h \ > > It is really not specific to arm64. We could rename it to rte_ring_c11_mem.h or > > something like that to reflect the implementation based on c11 memory > > model. > > > > > > > + rte_ring_generic.h > > > include $(RTE_SDK)/mk/rte.lib.mk > > > diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h > > > index 5e9b3b7..943b1f9 100644 > > > --- a/lib/librte_ring/rte_ring.h > > > +++ b/lib/librte_ring/rte_ring.h > > > @@ -103,6 +103,18 @@ extern "C" { > > > #include > > > #include > > > +/* In those strong memory models (e.g. x86), there is no need to add rmb() > > > + * between load and load. > > > + * In those weak models(powerpc/arm), there are 2 choices for the users > > > + * 1.use rmb() memory barrier > > > + * 2.use one-direcion load_acquire/store_release barrier > > > + * It depends on performance test results. */ > > > +#ifdef RTE_ARCH_ARM64 > > s/RTE_ARCH_ARM64/RTE_RING_USE_C11_MEM_MODEL and update the generic arm64 config. > > By that way it can used by another architecture like ppc if they choose to do so. > > > > > > > +#include "rte_ring_arm64.h" > > > +#else > > > +#include "rte_ring_generic.h" > > > +#endif > > > + > > > #define RTE_TAILQ_RING_NAME "RTE_RING" > > > enum rte_ring_queue_behavior { > > > @@ -368,7 +380,7 @@ update_tail(struct rte_ring_headtail *ht, uint32_t old_val, uint32_t new_val, > > > while (unlikely(ht->tail != old_val)) > > > rte_pause(); > > > - ht->tail = new_val; > > > + arch_rte_atomic_store(&ht->tail, new_val, __ATOMIC_RELEASE); > > > } > > > /** > > > @@ -408,7 +420,8 @@ __rte_ring_move_prod_head(struct rte_ring *r, int is_sp, > > > /* Reset n to the initial burst count */ > > > n = max; > > > - *old_head = r->prod.head; > > > + *old_head = arch_rte_atomic_load(&r->prod.head, > > > + __ATOMIC_ACQUIRE); > > Same as Konstantin comments, i.e move to this function to c11 memory model > > header file > > > > > const uint32_t cons_tail = r->cons.tail; > > > /* > > > * The subtraction is done between two unsigned 32bits value > > > @@ -430,8 +443,10 @@ __rte_ring_move_prod_head(struct rte_ring *r, int is_sp, > > > if (is_sp) > > > r->prod.head = *new_head, success = 1; > > > else > > > - success = rte_atomic32_cmpset(&r->prod.head, > > > - *old_head, *new_head); > > > + success = arch_rte_atomic32_cmpset(&r->prod.head, > > > + old_head, *new_head, > > > + 0, __ATOMIC_ACQUIRE, > > > + __ATOMIC_RELAXED); > > > } while (unlikely(success == 0)); > > > return n; > > > } > > > @@ -470,7 +485,10 @@ __rte_ring_do_enqueue(struct rte_ring *r, void * const *obj_table, > > > goto end; > > > ENQUEUE_PTRS(r, &r[1], prod_head, obj_table, n, void *); > > > + > > > +#ifndef RTE_ATOMIC_ACQUIRE_RELEASE_BARRIER_PREFER > > This #define will be removed if the function moves. > > > > > rte_smp_wmb(); > > > +#endif > > > update_tail(&r->prod, prod_head, prod_next, is_sp); > > > end: > > > @@ -516,7 +534,8 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc, > > > /* Restore n as it may change every loop */ > > > n = max; > > > - *old_head = r->cons.head; > > > + *old_head = arch_rte_atomic_load(&r->cons.head, > > > + __ATOMIC_ACQUIRE); > > > const uint32_t prod_tail = r->prod.tail; > > > /* The subtraction is done between two unsigned 32bits value > > > * (the result is always modulo 32 bits even if we have > > > @@ -535,8 +554,10 @@ __rte_ring_move_cons_head(struct rte_ring *r, int is_sc, > > > if (is_sc) > > > r->cons.head = *new_head, success = 1; > > > else > > > - success = rte_atomic32_cmpset(&r->cons.head, *old_head, > > > - *new_head); > > > + success = arch_rte_atomic32_cmpset(&r->cons.head, > > > + old_head, *new_head, > > > + 0, __ATOMIC_ACQUIRE, > > > + __ATOMIC_RELAXED); > > > } while (unlikely(success == 0)); > > > return n; > > > } > > > @@ -575,7 +596,10 @@ __rte_ring_do_dequeue(struct rte_ring *r, void **obj_table, > > > goto end; > > > DEQUEUE_PTRS(r, &r[1], cons_head, obj_table, n, void *); > > > + > > > +#ifndef RTE_ATOMIC_ACQUIRE_RELEASE_BARRIER_PREFER > > This #define will be removed if the function moves. > > > > > rte_smp_rmb(); > > > +#endif > > -- > Cheers, > Jia >