From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0074.outbound.protection.outlook.com [104.47.40.74]) by dpdk.org (Postfix) with ESMTP id 74E7F5F48 for ; Thu, 20 Sep 2018 17:37:27 +0200 (CEST) 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:X-MS-Exchange-SenderADCheck; bh=H0rovvs2/CxTIFstaLArRwXL3N5Vc/2b1Ue8/DBnrxc=; b=NtZVzQWzDKQvmRaMrhuc+hem2VYiklb8yVtiMcY6C38pfxZIxS5lKE5Q3tVWaW4szvaqtW7ezB/TRcTK6QVDBqdX/eiiDq50JwgxCn/jOOwDtaX45Xw3x0zVe8UoQQ8wU3uvXQdYRiCtZmjMPdCcYx50dxMgiiWtnGbvWInS0q4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (111.93.218.67) by SN6PR07MB5008.namprd07.prod.outlook.com (2603:10b6:805:ad::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.17; Thu, 20 Sep 2018 15:37:23 +0000 Date: Thu, 20 Sep 2018 21:07:02 +0530 From: Jerin Jacob To: Honnappa Nagarahalli Cc: "Phil Yang (Arm Technology China)" , "dev@dpdk.org" , nd , "kkokkilagadda@caviumnetworks.com" , "Gavin Hu (Arm Technology China)" , "ferruh.yigit@intel.com" Message-ID: <20180920153700.GA9459@jerin> References: <1537363820-3827-1-git-send-email-phil.yang@arm.com> <1537364560-4124-1-git-send-email-phil.yang@arm.com> <1537364560-4124-2-git-send-email-phil.yang@arm.com> <20180920082846.GB19425@jerin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Originating-IP: [111.93.218.67] X-ClientProxiedBy: BM1PR0101CA0025.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:1a::11) To SN6PR07MB5008.namprd07.prod.outlook.com (2603:10b6:805:ad::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7f591bfa-bfd8-4428-1eeb-08d61f0ef736 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:SN6PR07MB5008; X-Microsoft-Exchange-Diagnostics: 1; SN6PR07MB5008; 3:FBOqffvY+Nc72FOlNLaduVLvOyrUsq+8De9s25uAX9V69c7wTICvj0LSoXbkdkHYJr/KJ8zZ26eZg4YDs5BQtnIH9oubBYZU4Zo+T77V6vktn1+RhD3H1cpoUqZ65pf/A9aRTultrEG8JkKJzU8s7XTS18MEtKe2WPzMfOjwtqLh5ruQB5JfQ/vrg84eVh+ExgBcHpUzaxUTz4HdPGJ9HpvEb3VOeHbEYoHAcF7YllI+XhYS1Q4l9+BbN3T25TKh; 25:vB1JSqSBxX8wGOXIwfi6EJoiz0OSttBSKk/YUInJtTThkCjml75gDXSyKz8lsEkUB7HFjir8s3ABL5UO/zCQW6qz+oKm8M7r31XT4tp5XF3K1HbAmHSReXV5sax0S2tDx8kbjjsCZubR9g8cId+GOrphgjA+hry+q9iT6EQ5xJnz6X5h+hRn78xthN57vwIkARuNyOMBrjtCyj4tDF3LoYYZBj+84ocieOyC3Xj4k6/uCn4ts6GcTr/r/KGs7+TfPrb2rFvgk++ks1+R/y1jZ6DPBwZc+jUch26No32G4idoXEV2USBm8VDHj0dX4kba6Cn3fylBNQO8ONmkR44Bug==; 31:9DB+qk71oNkaMhvX7u7YmeqIH25S74Yv+vIrQsvcmpebukJbqHEuaiZSMHuUKnHE5H4Ru3r5XEAaKQVLrrN8zuMV2scpS441FyXNiHdYLAR+pfIe846SgXohSj2/Ez6dhaPPHdJ5xkIBuE8g21puWg2nyqX7u0b8gRJ0nc7hVuqPq0jbPgFmwC7XTmniDdcBlv0GxQ29dFLvEL3nuvgtasxKWVhY5P1PvJu5Q8wbpfc= X-MS-TrafficTypeDiagnostic: SN6PR07MB5008: X-Microsoft-Exchange-Diagnostics: 1; SN6PR07MB5008; 20:IGy0VbuULa++osKV2XxBVfbKmS5Swgfr1lLQXWo4L1WLZcEyQVjyABnAFmwVa0ysISoKhIxn5EH0DQlJg2LHOZJmXwDwj/IrT/ym/RfznFsEZOafLOCoO5DNLnYjqAYY2rt+K0+XbEpzHfDDPguEdYSQeojPdqNMTurgRszj9kXZdr/JioKEpUuV4DoLumtbBeiodN7zETu/qduZsn1m6XVFR0L/O//jrznkWqoW2nmzh1xmPWA3VbTGKUJC4mbbXqWIle0+rbFZXmoelnYYa9nYFNbf9FQfiLnQqPp/yWDXh4z1ce6yC0ifavvcg5g/dtCrQstrDwW2kK2BWgY7SS41ETQ4bWusNI4Rw5yvj1xlHnl0tVzoNRmmV+hF3pK6f2lqvfjetG5Xhi7qf2QTcxluFWnKYyAe8hjxtKd+cLuuHQiNPzI4vXqbtKOF0hC9K704oYNAAZnh/gMkogCdSpr4z6HVgoNyD6jQA0Pt2CdJi42VNwiQVOjZEyRTnFyFv3j1qyuGF/DkFQVaSw0Jw1R0ePczebUI8ms6lvJC1+P8qN33tHUvoQU4mgfjUEEh5MJ2mq28s+sJ81/yLGM0J6vhWXpYvHutTtHFY+c/yO0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(180628864354917)(163750095850)(228905959029699); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231355)(944501410)(52105095)(93006095)(149027)(150027)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(201708071742011)(7699051); SRVR:SN6PR07MB5008; BCL:0; PCL:0; RULEID:; SRVR:SN6PR07MB5008; X-Microsoft-Exchange-Diagnostics: 1; SN6PR07MB5008; 4:GTLhmx4ZlOHMS3OZVzOWhTMy6wZz8+4vvM/M9bUNKP+qpf9FLhsdqMDfCbCKGM9Y0n0zYz7OC1NLViW2+pU08HS3XvYMU/s27gA6sShaIqC0P0z3BfBu6qppy6N7mN/5/yBs/cFeCrn8PM7eOEQyYvQceKyY16GAhgcv2a2BKFInd5+thn2n0+Ek6EZRC/U/8kMTc/MbiJ42iSYuJy9aaoTHOiFX/5OY9W4tLGIBFy8nPEIUF61kqeuxnS5JjIcuFzq1BjM3/e5m4MIBc03lAwlvUwmBpvsYPvwY8XD+90VTtWV0IuVvNkYjTAax+0NClVEDhp56P7yEBYsnkoM65cxyErxvtSS88SmggqQoaCcTDTefJ2z6euKFXUVbts15 X-Forefront-PRVS: 0801F2E62B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(376002)(366004)(396003)(346002)(13464003)(57704003)(199004)(189003)(7736002)(76176011)(305945005)(52116002)(8936002)(3846002)(23726003)(6116002)(105586002)(4326008)(1076002)(93886005)(5009440100003)(81166006)(81156014)(33656002)(14444005)(97736004)(106356001)(33896004)(33716001)(68736007)(25786009)(42882007)(16586007)(478600001)(53936002)(9686003)(6916009)(6666003)(316002)(8676002)(2906002)(386003)(956004)(44832011)(476003)(11346002)(6496006)(72206003)(50466002)(5660300001)(486006)(229853002)(6246003)(66066001)(47776003)(26005)(54906003)(58126008)(16526019)(446003)(186003)(55016002)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR07MB5008; H:jerin; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR07MB5008; 23:Ol5ecOValp6qMjRJWekHRVfdUqbqtYgnTLiYUgpI4?= =?us-ascii?Q?Cem3WDj+DgkAS++5WfW4PZ6WzeRvRzP9Lbg26LMSTrxFN7s8dXmc3qS5cDMj?= =?us-ascii?Q?/1FLWBCN0zQNNVJ84+GV5CCecdPBiQ56ZD3r+5qwbIU1xW4VDvnUkpH3abYh?= =?us-ascii?Q?rb2tw/ch2l2KPVUMeSRWpNq13iBDhJpt66e9JwMX7aVbiVYtQPkyXNz4oS/6?= =?us-ascii?Q?rREy0UEva8TF6s3pOtKtwU1qiSN4igiZHTqYRh27wtK9s42vVpqRin2Tu6mJ?= =?us-ascii?Q?JXLNfX/toOES81i+7X0yogW6Ejv4JnG1WlSXTwdN2QQZSlMo4hqy1iGnPvoj?= =?us-ascii?Q?bFl6NJ7VhVQt1OkJEUM+na2W4LFPHyn9kfp1nm2nDsbjBmujtxmziWQzlpbB?= =?us-ascii?Q?D0HIq4xOtm2s2M4tUU0vMvcffct5C8c3WEx1cGBgOTHAGPFLQtEvOHSQ8Bhg?= =?us-ascii?Q?2CGwvK89xZ7SY4uVj1oNlpX6HjfwgtaoIJ1Fean3zYO6Rfio8y9YEXGj0mOJ?= =?us-ascii?Q?3T5/tPhc1NDZcBv5e+Pq1iFfEr58LvF7nCAeya5dl0E2E/jTtnX7jVMknjtZ?= =?us-ascii?Q?eCuWLdrXj2Tz3EUtY1nI//vy6Dj4xqz4Os+u315tyXUROdnxjnPU3OMlvpku?= =?us-ascii?Q?QftWnchh3yBfyd8wXl0m3SNWQyYb3PsjwzUt+S/kdq7gSmZtVKhnoS5vaAQ+?= =?us-ascii?Q?/waKPCFGYjfeEUbkql5Rw2hlQcSA2QmBpoaeN4WBG8oYQhVFSDq73gG+1X49?= =?us-ascii?Q?q0G2WLddgdpW7CbyMFXs/XT7ArvTkOkNOAL69egpjUTzuzYTvJgdatsb2LAq?= =?us-ascii?Q?ueRHoEzJ7kWPRak4BXQ0xGhLEtYHFOc9xfZsQffU63VD2GLjWF1NZmXwRfSX?= =?us-ascii?Q?yF9mO0QJIS1vectxIzxcY1qm2CRUcMTYdBr+szFWeHSbY2GrTMFxnRZxk2mV?= =?us-ascii?Q?Fnp/AZ/DLXr+lk92E1NYG2r4hhzxHlVAZ/O2DxRPtM1y98ciAFd7dXDf2SK4?= =?us-ascii?Q?M7QuL9uyI5sLiPAhMiEiDssci8AZw5LzIn34Ng3Q1kve0WHOLamNFDE+rbVD?= =?us-ascii?Q?eE3aXe5yYojn2i9o5X43QAel/ez8SYEv/xqu3y7pAD7SiL2K+b0SYdglInkA?= =?us-ascii?Q?/UrOwpVGKMynl9GHFkaElc1evMpU5uhXej9DNQBi4l+IKo43vsIpZpT1SQgx?= =?us-ascii?Q?5AxkR/UP6Rn8CDvblyT01rBkb4T/3jwuC3wJYP/9sq1I4dmQGQyHOgZCsFbF?= =?us-ascii?Q?xdJPcIUj2kRhApnvfCkIVdSTLh5p4ppOwj74o3Lnw5XuKT0J/I/2ISN/5Rh8?= =?us-ascii?Q?lIakCmqdOHwuLa/DNiu091DHZ/PuL7eSA1ExkjAflGq8C2hpIPaXWeqMUSE1?= =?us-ascii?Q?k37qiqISlIc/LewCG+ijkJuEHFo+x9ItnLSgdBc4oxbaL82Mroqhif4jI40m?= =?us-ascii?Q?2b07/lUoz/QOHbvp0WbMnIek6GS9nY=3D?= X-Microsoft-Antispam-Message-Info: tjM9ohAtGzDBkovntE06mpWn+6yPzZ7NIM5/p9NHv382PHEkKbx/OelX0qyCgZRNVWYhnxUEn1E6Om5AEgim2j6IV/13mgpg5TV0hfzqG8wSoaGkX+NS19yDo63XDjFb926XXNokWVZQzwUwgZpAAImHWxk8/RIDD61HRgoEnK4TTf4DQejtFbLGUZR4pXsnGl7AbKnNf16J6ZtUepXASCSYi4TXdVaOIvqk1jxOh4YZdS0yLC2c3LBZkPnGoziD1Vty6hXAHMB/qDZGTlot9IAR1GMKJX3376cYxAD1KdxERUg/QJ6zd5Lc+ig3hlentsBdvRFsuypUA6MlrQoezoAhqpKpLfnwOFEi+f6q+GY= X-Microsoft-Exchange-Diagnostics: 1; SN6PR07MB5008; 6:K3HK1AC9gaOlnVS1siVsep8l3A7ipbjvSq3Ys6/OQYEVmJcxTuu+bh2f3W+cvQbapN0pbc1QeVEytYWsOJEvWlXqC5J6nPGKZASDadNNQBaUXbPq4oZl0Mc6Si8QaWg6OqMC2B33PXJCIsoHmZPu7bB9CcwGthW7YHE2m7X1vPX3tgigPv5blGDhFB53C06nkpGMu88wDWLKNdsBRYLqYHw7QEQYZxnB29B8fzb70VdOMLB8M9YhH65FF9IokH8qk2KBeMRNeBuua93Ht8/MScDJW/WvF5tSrq9U7vrIjp7Z9u7aCEYa5hfT/MVn6b/+C/cREKnfV53sOv+dsIfCwZWhniPA1x8QpWP3aobv8svqMBfDkI5FyoX8Uwf+pSDgmVjim4m/WrvS9uixOmJOmf+Ri720HC5yqUvxxKwkI8R6QCuaW8/9zYjgBFKgT/Nqpo1VQL1PKHUGpIaTIVxiEg==; 5:wiOZ81X03dAw+7ApxVhzIncKerflS4EYPnDwgzzmdlUBuTO0kJsCUWZy33OdjcHOMpnVxfQuFf0p9ZEDcEW52LP/tyn/3jO9T5OiheUUmjoa2T8/Y9QdoK2CFN/qJUUmfk34+YUBEVNBY3KDFGuImselM/n6Wk1Ixvh+nOJPM2s=; 7:ix77vf3QzKFsljD86M4IckEPmuKJ/xFWrNq1agIcdcTqp/2AS3hxLWYLXRc+a1oZo4LtRCshGEBI9GHCZZ8FEILKAKbJkMn1qKPlbGZ2azRtu8hO+kk4dzhXCmrxH5JhXM/QQuhGCW8vL8lygibyf6zQYT0c3bwS2v+k7VgRadMEBwPZVqQy5qQsp4S/VilnkcTpefoGf7P2crA2SwaqJvDYyDYAhZ9Elf+5Tp05/l32ip9/rB4Vg+mkzG/AWunb SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2018 15:37:23.4380 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7f591bfa-bfd8-4428-1eeb-08d61f0ef736 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR07MB5008 Subject: Re: [dpdk-dev] [PATCH v2 2/3] kni: fix kni fifo synchronization 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, 20 Sep 2018 15:37:28 -0000 -----Original Message----- > Date: Thu, 20 Sep 2018 15:20:53 +0000 > From: Honnappa Nagarahalli > To: Jerin Jacob , "Phil Yang (Arm > Technology China)" > CC: "dev@dpdk.org" , nd , > "kkokkilagadda@caviumnetworks.com" , > "Gavin Hu (Arm Technology China)" , > "ferruh.yigit@intel.com" > Subject: RE: [PATCH v2 2/3] kni: fix kni fifo synchronization > > > > -----Original Message----- > > > Date: Wed, 19 Sep 2018 21:42:39 +0800 > > > From: Phil Yang > > > To: dev@dpdk.org > > > CC: nd@arm.com, jerin.jacob@caviumnetworks.com, > > > kkokkilagadda@caviumnetworks.com, Honnappa.Nagarahalli@arm.com, > > > Gavin.Hu@arm.com > > > Subject: [PATCH v2 2/3] kni: fix kni fifo synchronization > > > X-Mailer: git-send-email 2.7.4 > > > > > > > + Ferruh Yigit > > > > > > > > With existing code in kni_fifo_put, rx_q values are not being updated > > > before updating fifo_write. While reading rx_q in kni_net_rx_normal, > > > This is causing the sync issue on other core. The same situation > > > happens in kni_fifo_get as well. > > > > > > So syncing the values by adding C11 atomic memory barriers to make > > > sure the values being synced before updating fifo_write and fifo_read. > > > > > > Fixes: 3fc5ca2 ("kni: initial import") > > > Signed-off-by: Phil Yang > > > Reviewed-by: Honnappa Nagarahalli > > > Reviewed-by: Gavin Hu > > > --- > > > .../linuxapp/eal/include/exec-env/rte_kni_common.h | 5 ++++ > > > lib/librte_kni/rte_kni_fifo.h | 30 +++++++++++++++++++++- > > > 2 files changed, 34 insertions(+), 1 deletion(-) > > > > > > diff --git > > > a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h > > > b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h > > > index cfa9448..1fd713b 100644 > > > --- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h > > > +++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h > > > @@ -54,8 +54,13 @@ struct rte_kni_request { > > > * Writing should never overwrite the read position > > > */ > > > struct rte_kni_fifo { > > > +#ifndef RTE_USE_C11_MEM_MODEL > > > volatile unsigned write; /**< Next position to be written*/ > > > volatile unsigned read; /**< Next position to be read */ > > > +#else > > > + unsigned write; /**< Next position to be written*/ > > > + unsigned read; /**< Next position to be read */ > > > +#endif > > > unsigned len; /**< Circular buffer length */ > > > unsigned elem_size; /**< Pointer size - for 32/64 bit OS */ > > > void *volatile buffer[]; /**< The buffer contains mbuf pointers */ > > > diff --git a/lib/librte_kni/rte_kni_fifo.h > > > b/lib/librte_kni/rte_kni_fifo.h index ac26a8c..f4171a1 100644 > > > --- a/lib/librte_kni/rte_kni_fifo.h > > > +++ b/lib/librte_kni/rte_kni_fifo.h > > > @@ -28,8 +28,13 @@ kni_fifo_put(struct rte_kni_fifo *fifo, void > > > **data, unsigned num) { > > > unsigned i = 0; > > > unsigned fifo_write = fifo->write; > > > - unsigned fifo_read = fifo->read; > > > unsigned new_write = fifo_write; > > > +#ifdef RTE_USE_C11_MEM_MODEL > > > + unsigned fifo_read = __atomic_load_n(&fifo->read, > > > + __ATOMIC_ACQUIRE); > > > +#else > > > + unsigned fifo_read = fifo->read; #endif > > > > Correct. > > My apologies, did not follow your comment here. Do you want us to correct anything here? '#endif' is not appearing on the correct line in the email, but it shows up fine on the patch work. No. What I meant is, code is correct. > > > > > > > > > > > for (i = 0; i < num; i++) { > > > new_write = (new_write + 1) & (fifo->len - 1); @@ > > > -39,7 +44,12 @@ kni_fifo_put(struct rte_kni_fifo *fifo, void **data, > > unsigned num) > > > fifo->buffer[fifo_write] = data[i]; > > > fifo_write = new_write; > > > } > > > +#ifdef RTE_USE_C11_MEM_MODEL > > > + __atomic_store_n(&fifo->write, fifo_write, __ATOMIC_RELEASE); > > > +#else > > > + rte_smp_wmb(); > > > fifo->write = fifo_write; > > > +#endif > > > > Correct. > > > return i; > > > } > > > > > > @@ -51,7 +61,12 @@ kni_fifo_get(struct rte_kni_fifo *fifo, void > > > **data, unsigned num) { > > > unsigned i = 0; > > > unsigned new_read = fifo->read; > > > +#ifdef RTE_USE_C11_MEM_MODEL > > > + unsigned fifo_write = __atomic_load_n(&fifo->write, > > > +__ATOMIC_ACQUIRE); #else > > > unsigned fifo_write = fifo->write; > > > +#endif > > > > Correct. > > > > > + > > > for (i = 0; i < num; i++) { > > > if (new_read == fifo_write) > > > break; > > > @@ -59,7 +74,12 @@ kni_fifo_get(struct rte_kni_fifo *fifo, void **data, > > unsigned num) > > > data[i] = fifo->buffer[new_read]; > > > new_read = (new_read + 1) & (fifo->len - 1); > > > } > > > +#ifdef RTE_USE_C11_MEM_MODEL > > > + __atomic_store_n(&fifo->read, new_read, __ATOMIC_RELEASE); > > > +#else > > > + rte_smp_wmb(); > > > fifo->read = new_read; > > > +#endif > > > > Correct. > > > > > return i; > > > } > > > > > > @@ -69,5 +89,13 @@ kni_fifo_get(struct rte_kni_fifo *fifo, void > > > **data, unsigned num) static inline uint32_t kni_fifo_count(struct > > > rte_kni_fifo *fifo) { > > > +#ifdef RTE_USE_C11_MEM_MODEL > > > + unsigned fifo_write = __atomic_load_n(&fifo->write, > > > + __ATOMIC_ACQUIRE); > > > + unsigned fifo_read = __atomic_load_n(&fifo->read, > > > + __ATOMIC_ACQUIRE); > > > > Isn't too heavy to have two __ATOMIC_ACQUIREs? a simple rte_smp_rmb() > > would be enough here. Right? > > or > > Do we need __ATOMIC_ACQUIRE for fifo_write case? > > > We also had some amount of debate internally on this: > 1) We do not want to use rte_smp_rmb() as we want to keep the memory models separated (for ex: while using C11, use C11 everywhere). It is also not sufficient, please see 3) below. But Nothing technically wrong in using rte_smp_rmb() here in terms functionally and code generated by the compiler. > 2) This API can get called from writer or reader, so both the loads have to be __ATOMIC_ACQUIRE > 3) Other option is to use __ATOMIC_RELAXED. That would allow any loads/stores around of this API to get reordered, especially since this is an inline function. This would put burden on the application to manage the ordering depending on its usage. It will also require the application to understand the implementation of this API. __ATOMIC_RELAXED may be fine too for _count() case as it may not very important to get the exact count for the exact very moment, Application can retry. I am in favor of performance effective implementation. > > > > > Other than that, I prefer to avoid ifdef clutter by introducing two separate file > > just like ring C11 implementation. > > > > I don't have strong opinion on this this part, I let KNI MAINTAINER to decide > > on how to accommodate this change. > > I prefer to change this as well, I am open for suggestions. > Introducing two separate files would be too much for this library. A better way would be to have something similar to 'smp_store_release' provided by the kernel. i.e. create #defines for loads/stores. Hide the clutter behind the #defines. No Strong opinion on this, leaving to KNI Maintainer. This patch needs to split by two, a) Fixes for non C11 implementation(i.e new addition to rte_smp_wmb()) b) add support for C11 implementation. > > > > > > + return (fifo->len + fifo_write - fifo_read) & (fifo->len - 1); > > > +#else > > > return (fifo->len + fifo->write - fifo->read) & (fifo->len - > > > 1); > > > +#endif > > > } > > > -- > > > 2.7.4 > > >