From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 7260D8E6C for ; Tue, 3 Nov 2015 17:24:39 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP; 03 Nov 2015 08:24:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,239,1444719600"; d="scan'208";a="825881742" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by fmsmga001.fm.intel.com with ESMTP; 03 Nov 2015 08:24:37 -0800 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.116]) by irsmsx105.ger.corp.intel.com ([169.254.7.75]) with mapi id 14.03.0248.002; Tue, 3 Nov 2015 16:24:36 +0000 From: "Richardson, Bruce" To: Jerin Jacob , "Ananyev, Konstantin" Thread-Topic: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter Thread-Index: AQHRFlNtvkfUftDDJESs/4mJqnavcJ6Ke1yw Date: Tue, 3 Nov 2015 16:24:35 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B0359679D6@IRSMSX103.ger.corp.intel.com> References: <1446565921-18088-1-git-send-email-jerin.jacob@caviumnetworks.com> <2601191342CEEE43887BDE71AB97725836AB8F01@irsmsx105.ger.corp.intel.com> <20151103161834.GA18450@localhost.localdomain> In-Reply-To: <20151103161834.GA18450@localhost.localdomain> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [RFC ][PATCH] Introduce RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 16:24:39 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob > Sent: Tuesday, November 3, 2015 4:19 PM > To: Ananyev, Konstantin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [RFC ][PATCH] Introduce > RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter >=20 > On Tue, Nov 03, 2015 at 03:57:24PM +0000, Ananyev, Konstantin wrote: > > > > > > > -----Original Message----- > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob > > > Sent: Tuesday, November 03, 2015 3:52 PM > > > To: dev@dpdk.org > > > Subject: [dpdk-dev] [RFC ][PATCH] Introduce > > > RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration parameter > > > > > > rte_ring implementation needs explicit memory barrier in weakly > > > ordered architecture like ARM unlike strongly ordered architecture > > > like X86 > > > > > > Introducing RTE_ARCH_STRONGLY_ORDERED_MEM_OPS configuration to > > > abstract such dependency so that other weakly ordered architectures > > > can reuse this infrastructure. > > > > Looks a bit clumsy. > > Please try to follow this suggestion instead: > > http://dpdk.org/ml/archives/dev/2015-October/025505.html >=20 > Make sense. Do we agree on a macro that is defined based upon > RTE_ARCH_STRONGLY_ORDERED_MEM_OP to remove clumsy #ifdef every where ? >=20 > Jerin Yes to the single-defined barrier macro. However, for what controls it, is it really worthwhile defining a new RTE_ = variable for it? Can we not base it on RTE_ARCH directly? /Bruce