From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0051.outbound.protection.outlook.com [104.47.37.51]) by dpdk.org (Postfix) with ESMTP id CC9EE1B650 for ; Thu, 2 Nov 2017 18:01:17 +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=erejPopf2GZlua1q69+igM4FoeKtDe8RlKJBy6MxK9k=; b=ANR5oaXcV599HYrxCDfw9gWCay5Dwaa7Eutfv6NOJdSh1IscvIo6OmZGBxt0jVI7JFaChLHKGG5BNwIHWgrbJxC0OXJ/gqgezeAqJHfFfz4oTtUx3DhoIEj0QnzqUBNSThoGY+W2ApfTFvcoXEnPbDj4B3+WdiJ8jagCk5kii74= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (106.201.55.141) by BN3PR07MB2515.namprd07.prod.outlook.com (10.167.4.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Thu, 2 Nov 2017 17:01:12 +0000 Date: Thu, 2 Nov 2017 22:30:56 +0530 From: Jerin Jacob To: "Ananyev, Konstantin" Cc: Jia He , "dev@dpdk.org" , "olivier.matz@6wind.com" , "Richardson, Bruce" , "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: <20171102170054.GA1478@jerin> References: <1509612210-5499-1-git-send-email-hejianet@gmail.com> <2601191342CEEE43887BDE71AB9772585FAB8703@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772585FAB8891@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB9772585FAB8891@irsmsx105.ger.corp.intel.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Originating-IP: [106.201.55.141] X-ClientProxiedBy: PN1PR0101CA0028.INDPRD01.PROD.OUTLOOK.COM (10.174.150.14) To BN3PR07MB2515.namprd07.prod.outlook.com (10.167.4.140) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 476e3726-2c7b-481d-f76e-08d522135420 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:BN3PR07MB2515; X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2515; 3:i62jhVdZfe+KSRkIjHigLxWuZdy9Ed0Cbnal3OeFvn40ocexHKuFYbvQ/SMpSWJy8zo9eLGo69/l0/vOWkjX82+gm5Anww7Imzi9z7mVLKkn4cqGIdzoh4dflOlNDLOk0nrYKSYcV1W4ytsdfQ6o96g8ziyrzWY81PGbFiIa1H4Y1DwylrFwWY4j2Bj+gvUmqBQLaMaYsUm/WZpyeza9B1v9pQx7Q6y7Allj/KH8yxxsJmofFyDLkZ+YYAmWxeH0; 25:T7kVeo+A9QsJBrmzNqi1CvEepfP4YHN4UlpuMTtcK87+QWeSGNWFJmEy+j18QL3pwYfvdmB/nao1PQoQgNXbAEmjPe1ZemkmhndcyI7SnTXhc68VN9tCkIXqAoy5TEARmB9Qpjld11II0bE3wpgRUu2fjMRE5W/Oc/ui/5QM2FJR+4FASamazuNTCIilUDSQFvoBw3WmQXcx/DlKgcuFiTzfVf2OzcCCI3pQwtV90za6dTbvZnxB3YdoTIY2uyRJHWg0V/ie5jO4L78M3Pj7Rrz+whemOz1fVzTTcgcuS2xTmJ9ys23jmyICnC47L7drVOzmLvLeHoPE0LEmRdyPsA==; 31:wTfwgYmlV2Xa7YtE4skDM4pfS0n2L+CdkL+VFwthM37N1wEmkZN7oQJXFvtFXRijdXKd0uvQcvfHY9nzNyfIUeoYesm9qV7KcLg0fq0Mdv9MIS7izJR3aeFOBXIMmPYfcgbgP8EA/XtkiRXY4KdGeIEejuw5OompfKmwfx1LGUVpA5/Jkw0C6cMW0cwpaE7z+KPj5nngDW4aajUzkxjhXR6tkIwy2RfAdl3zGe3XyVk= X-MS-TrafficTypeDiagnostic: BN3PR07MB2515: X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2515; 20:HdlXog5w+eQ/LLsNEGrHu1dq3VBWOmPY28ca9Pu7tLpSa/I68b4JsX2aH1BfI2Xd52R1IT1A/HfSlW8y6sj+Ny0k5vDBaCAnGi4scceMAD6KKSOa3B7IJLqROZYKGjcK+s3u42Fh+3n405/1lVvvFxldBEKgtrk49tdf4bkMkuz8lOgWML2Mz/kXIviyxM/X0uHzs/ErySJsSP39w+2ArGzHA+4rw3RhVk+yRSL5FbEAj4+i45bX7iZFVkmSGK8Dzxxyfc/ystJzeJRool5TBEM9DB8pjM+5PA+r2EkRICu9vyw5HC5+9ZjHTR3uzjr3BgItt9OQ5ENR7K1sOdxtyEVu1rUwdFfuPUTQ8uUBoPgkzopxjZut17wRgoMUBTd1MCfb8FHYoWC1G7V8ai+d2Yq6/hsGkmqUSQ4MWmFh9hBGLEA0YauP4eNRXG32rAmwv74JSCkl9IjJHjDNK02GpO2P58pkYcUKebiVnWt6/Gx4SA6AW41bVg6AlNkUgcF9rOzxH1RGOktSYoZglhH2X60tRyZguoVKuAoTPavB+5fFrsS5xecnBUgt432r/pi1L2oUaDanyVFw3OyLE/9Uae0dIWFcDERIzK9BTXdlGDA= X-Exchange-Antispam-Report-Test: UriScan:(180628864354917)(166708455590820)(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)(5005006)(8121501046)(3231020)(93006095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR07MB2515; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR07MB2515; X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2515; 4:qnZ9uojQz2AXS3BXoWmm5FQisRaWSjEHACegNSFEqBBu5HBvpiFmfKtj5j/4laAbQMTo06oq2+dbLvo43GL6W8E5edZh07fu0Ki2v3HLFaJ+/VGk0KxE0LB3MTBVsByLxgh0POX90easdTedkPpKOfe/zjIl7CjWo/R39lCcQOnaJ/O1Urdp2I7FGenwmvPK8ZmIIu8NSAt3aEA7rCREr8iS0LtjpVGrrxdFHo4uc0xNCJoJyckPpHGog68tl1SWl8niInJOR8PS3m7lNgca5Z9iKUOjgqYnLGft5M09CHmt8+1zCbA8XU41DgsyL8tpdN3RRVD0A6e8RXHbw5fcQk+LVnZ/TuGfTAltn3mnxfk+T+nIgv1KlaSXaoK3R99WTZDT6nTX9hzdRTVDCzkZ6VnvpvWbhIrHKHl1booS3qI= X-Forefront-PRVS: 047999FF16 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(54534003)(13464003)(24454002)(199003)(189002)(42882006)(4326008)(8936002)(106356001)(25786009)(97736004)(6306002)(5009440100003)(68736007)(2906002)(7416002)(9686003)(55016002)(189998001)(3846002)(1076002)(6116002)(8656006)(23726003)(101416001)(6666003)(33656002)(6916009)(76176999)(2950100002)(50986999)(54356999)(5660300001)(50466002)(39060400002)(105586002)(53376002)(33716001)(53936002)(305945005)(6246003)(6496005)(16526018)(53546010)(7736002)(966005)(72206003)(83506002)(47776003)(93886005)(229853002)(58126008)(478600001)(16586007)(8676002)(66066001)(54906003)(81166006)(81156014)(316002)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR07MB2515; 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; BN3PR07MB2515; 23:AWDapfAwd/mbGfbdntykhHYTciFsfql2LCsD1MAHC?= =?us-ascii?Q?9xrAPCJqwxLJ3/KFO+Ri3RyFW1UjJtm98n1zIIzgo2q2C44e1fqMCi5YzFBT?= =?us-ascii?Q?1lGYxCsQ+rQNd/DFe7WGRWDo8VNv0S2LNPUsbZrp+Z9AjphZIHLpqa6X1dH+?= =?us-ascii?Q?+87Qf8+yUMoVUkGv8aRJ9uO5bVRSzDrMzYgVd2a/VbETbcGHUqG1SavHt76S?= =?us-ascii?Q?LnMUqaqJkodtlVpKdRqbiciLSbjxxlCnTD7MPSfNQRvmdrs7pDOqnK85LNEA?= =?us-ascii?Q?ga5YdHwRkUvBc0g4LIUr+lnwIMtkwfkMHdptcKn3OboszpspEe4a+I1G63MI?= =?us-ascii?Q?9ACDLf7ST6lfSL9R5WiKMotYp5pAN6eKzhJQwOsOSjfQZ9bj0oJyeI2SKP1b?= =?us-ascii?Q?ngKaHsZE4he/496xwgupdlxc09vSQpV7IbVamoVOVrJHjnlp+x/0fqb62vDm?= =?us-ascii?Q?nCYPFSlhNh9SI8HLwsJuV9fuGHf0gA8r/OwMSJMeHsc7Iqyc2uWFtnYv5a9X?= =?us-ascii?Q?fTKkgZ4SeoBXDTrjtI2vxoaUuAwOyYd86c0zYo4bArQikA0y4uPf79usBX9V?= =?us-ascii?Q?5oVJpUZjAtDgPfpOStDDEFkbrbKhRnujWHGb1fv0id50Clq/M1Z6aoTGm2bS?= =?us-ascii?Q?A2+Abm7bkatQ/vdDSjNnj61u7xdnbWD7FhDEuBINc8tAXu6j6iCtGGI+wO0E?= =?us-ascii?Q?V88FJQmRdbcChkv4QlTUIQAMtTCmITjNWph3Carx+oNZTUrbYPD44slETwJe?= =?us-ascii?Q?ia18ADY68auMkky5jHa5JnlpprhM/vNRwodjmswPcUvdkoInOjrHlPOvg2rW?= =?us-ascii?Q?OEsGJPqoQR65CM6pvGUs4PgLLvafudsdAV8lIMg/VW/f3Mmp/UEUboktWrvx?= =?us-ascii?Q?WzC2MB0xjGS/gJmsuc6dJ1Au5cFHH7mmpEexalCr2rPSZ0PBxhdg296ddFSb?= =?us-ascii?Q?AwAye2NqT77caCHZl81/ITPoFX6pGVJqKCk8gWRqxebWNU2JcOES2HxwxNLI?= =?us-ascii?Q?0+GYedgJ6yyKw7V/8RZg5pTfBOWxEGzwsQs1n6DnI1XXG9Qf3nwuDCj6Omdu?= =?us-ascii?Q?lnsfHej2UupV+CE0dVezNy8ldBO+XzlFDkMeZ30Dqo6g1h4hoR2SiOt5q69r?= =?us-ascii?Q?UvHjP+vxnY50d27TwFkAKHssdI0jpuUSvgnMZ8J2GFkdBn0iJpC8Q0lWuMKR?= =?us-ascii?Q?68bqTQVyaLm1apwDwg2usHnztac6KNcOKkGCNmxEQsQ62dDQ1GHQf6tuL8DQ?= =?us-ascii?Q?zlC7RdnbInv8TuaGhIuVgsOQkfyd/E07CCg/f9PFnhzjQ+sZXprqquXh3SNO?= =?us-ascii?Q?nG6bbjlSPIyjwAkiGw3uyfQoxoNKO+5x+VneKUJR9ds5/Uv5sJjNfkruWBrq?= =?us-ascii?Q?H+5cgQZI5KAk2bJO7pE8+MO8+dyAzwmrwVVES5iSXlz+08Dbhbb/ahF7hxeL?= =?us-ascii?Q?hqJtQUsx8a3KUhqSaCteRD9rzcTm7NgTpjuR17Cyfk8ZGBoVExm?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR07MB2515; 6:vcyU9ma4BaLTjcvPll23aALtnfTKNZSfQbr0Bnb2P81uWg5n9LGl7kMViY8iXUGvbbMPZw+OKjFaPLUclRv1WeLXUJyUs7dWZ6gwafDCknI/KE5sFRB5AmOtISUftISKVmxEEAmMjYbwEKA8C8el0zOYAE+ZDZwD67F1lCm3uKtsm3ByY7M0XO5uFeJjMkVjOjrh4s/Ao3ASGJUFLcnay/y18zU+jiOp88+fY+T2qvHaTxFDxqzZan69N5dyTrgLW/ooxQEo4q5C8dD7iB7Tk5ECrnUQKfIrmLQfWR6lbPtGlTnsVYbWIfUYruer0VD7EUh/kMaiOl9aPYDOgEMyAbxEZGRrDPL3660GHiuyjks=; 5:dHXtb7JKuri1iOcgbbeHOSd01OHfLqt4dUtnrUtHJuAu1L8HESk/pTSRBDZ/iB+lOzDtS2BnpWFNkHG2PUqk3Tf+p6fh/jcq4Y5NcDrnx4SAQCR6a6zNV/kYZv3tRSUHld6KxP5GsZdb23YBJrIPdfBqF25o/6th5/2Lnn29iTA=; 24:/wvH/h0hhTDMfuIqzLFE+uSCA1Q1k2PyO0J9hn+Kul6VwSaRqISAak+EZk7R7ReXjborLEp6b70omh8p2Xwd22KpksGZ3UgckN2tQJ55GHg=; 7:38VmrI4mQYdfmaiL61w3l0GQ+gENxkAXyokULqMwEr4B2cIL4zp8ZGXTazP6DxQIRP9Wz0Eg5uR0zNY7HMLztdQN1n/ccIasU/Z2wQPbDYm9ry0l+Y9H1eVl3OxdYiTwxdVMQE/mWpzj9PbOG/VXDxzGH1iKgLroY8xiIqe0tKcivS0KCudq4flg/uIb6MoqNJGZvq9BTrmksMZFJYAq5SLnAU4imI4WCTbTfNjw+b5S4O+179261oWlX6k7+Qvl SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2017 17:01:12.0682 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 476e3726-2c7b-481d-f76e-08d522135420 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR07MB2515 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: Thu, 02 Nov 2017 17:01:18 -0000 -----Original Message----- > Date: Thu, 2 Nov 2017 16:16:33 +0000 > From: "Ananyev, Konstantin" > To: Jia He , "jerin.jacob@caviumnetworks.com" > , "dev@dpdk.org" , > "olivier.matz@6wind.com" > CC: "Richardson, Bruce" , "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 > > > > > -----Original Message----- > > From: Jia He [mailto:hejianet@gmail.com] > > Sent: Thursday, November 2, 2017 3:43 PM > > To: Ananyev, Konstantin ; jerin.jacob@caviumnetworks.com; dev@dpdk.org; olivier.matz@6wind.com > > Cc: Richardson, Bruce ; 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 > > > > Hi Ananyev > > > > > > On 11/2/2017 9:26 PM, Ananyev, Konstantin Wrote: > > > Hi Jia, > > > > > >> -----Original Message----- > > >> From: Jia He [mailto:hejianet@gmail.com] > > >> Sent: Thursday, November 2, 2017 8:44 AM > > >> To: jerin.jacob@caviumnetworks.com; dev@dpdk.org; olivier.matz@6wind.com > > >> Cc: Ananyev, Konstantin ; Richardson, Bruce ; 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 > > >> > > >> We watched a rte panic of mbuf_autotest in our qualcomm arm64 server. > > >> As for the possible race condition, please refer to [1]. > > >> > > >> 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 > > >> default it is n; > > >> > > >> The reason why providing 2 options is due to the performance benchmark > > >> difference in different arm machines, please refer to [3]. > > >> > > >> Already fuctionally tested on the machines as follows: > > >> on X86(passed the compilation) > > >> on arm64 with CONFIG_RTE_ATOMIC_ACQUIRE_RELEASE_BARRIER_PREFER=y > > >> on arm64 with CONFIG_RTE_ATOMIC_ACQUIRE_RELEASE_BARRIER_PREFER=n > > >> > > >> [1] http://dpdk.org/ml/archives/dev/2017-October/078366.html > > >> [2] https://github.com/freebsd/freebsd/blob/master/sys/sys/buf_ring.h#L170 > > >> [3] http://dpdk.org/ml/archives/dev/2017-October/080861.html > > >> > > >> --- > > >> 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 \ > > >> + 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 > > >> +#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); > > >> const uint32_t cons_tail = r->cons.tail; > > > The code starts to look a bit messy with all these arch specific macros... > > > So I wonder wouldn't it be more cleaner to: > > > > > > 1. move existing __rte_ring_move_prod_head/__rte_ring_move_cons_head/update_tail > > > into rte_ring_generic.h > > > 2. Add rte_smp_rmb into generic __rte_ring_move_prod_head/__rte_ring_move_cons_head > > > (as was in v1 of your patch). > > > 3. Introduce ARM specific versions of __rte_ring_move_prod_head/__rte_ring_move_cons_head/update_tail > > > in the rte_ring_arm64.h > > > > > > That way we will keep ogneric code simple and clean, while still allowing arch specific optimizations. > > Thanks for your review. > > But as per your suggestion, there will be at least 2 copies of > > __rte_ring_move_prod_head/__rte_ring_move_cons_head/update_tail. > > Thus, if there are any bugs in the future, both 2 copies have to be > > changed, right? > > Yes, there would be some code duplication. > Though generic code would be much cleaner and simpler to read in that case. > Which is worth some dups I think. I agree with Konstantin here.