From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 6DBDC2C57 for ; Fri, 13 Jan 2017 15:31:12 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP; 13 Jan 2017 04:04:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,221,1477983600"; d="scan'208";a="922113343" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by orsmga003.jf.intel.com with ESMTP; 13 Jan 2017 04:04:45 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.38]) by IRSMSX152.ger.corp.intel.com ([169.254.6.191]) with mapi id 14.03.0248.002; Fri, 13 Jan 2017 12:04:44 +0000 From: "Ananyev, Konstantin" To: "Richardson, Bruce" , "Yigit, Ferruh" CC: Jerin Jacob , "dev@dpdk.org" , "thomas.monjalon@6wind.com" , "jianbo.liu@linaro.org" , "viktorin@rehivetech.com" , "santosh.shukla@caviumnetworks.com" , "Griffin, John" , "Trahe, Fiona" , "Jain, Deepak K" Thread-Topic: [dpdk-dev] [PATCH v3 15/29] crypto/qat: use eal I/O device memory read/write API Thread-Index: AQHSbLUHmwUl4CshZEumfSib23oEwqE1NVkAgADcFoCAADi5AIAAAfOAgAAEpAA= Date: Fri, 13 Jan 2017 12:04:43 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583F104E07@irsmsx105.ger.corp.intel.com> References: <1482832175-27199-1-git-send-email-jerin.jacob@caviumnetworks.com> <1484212646-10338-1-git-send-email-jerin.jacob@caviumnetworks.com> <1484212646-10338-16-git-send-email-jerin.jacob@caviumnetworks.com> <6bb9980b-f546-38d5-044a-63507510f6a5@intel.com> <20170113081641.GA17635@localhost.localdomain> <76c8ede9-54bb-51ba-293b-583681616e0a@intel.com> <20170113114705.GA188532@bricha3-MOBL3.ger.corp.intel.com> In-Reply-To: <20170113114705.GA188532@bricha3-MOBL3.ger.corp.intel.com> Accept-Language: en-IE, 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 Subject: Re: [dpdk-dev] [PATCH v3 15/29] crypto/qat: use eal I/O device memory read/write API 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, 13 Jan 2017 14:31:13 -0000 > -----Original Message----- > From: Richardson, Bruce > Sent: Friday, January 13, 2017 11:47 AM > To: Yigit, Ferruh > Cc: Jerin Jacob ; dev@dpdk.org; Ananyev, = Konstantin ; > thomas.monjalon@6wind.com; jianbo.liu@linaro.org; viktorin@rehivetech.com= ; santosh.shukla@caviumnetworks.com; Griffin, John > ; Trahe, Fiona ; Jain, Dee= pak K > Subject: Re: [dpdk-dev] [PATCH v3 15/29] crypto/qat: use eal I/O device m= emory read/write API >=20 > On Fri, Jan 13, 2017 at 11:40:06AM +0000, Ferruh Yigit wrote: > > On 1/13/2017 8:17 AM, Jerin Jacob wrote: > > > On Thu, Jan 12, 2017 at 07:09:22PM +0000, Ferruh Yigit wrote: > > >> Hi Jerin, > > >> > > >> On 1/12/2017 9:17 AM, Jerin Jacob wrote: > > >> <...> > > >> > > >>> +#include > > >>> + > > >>> /* CSR write macro */ > > >>> -#define ADF_CSR_WR(csrAddr, csrOffset, val) \ > > >>> - (void)((*((volatile uint32_t *)(((uint8_t *)csrAddr) + csrOffset)= ) \ > > >>> - =3D (val))) > > >>> +#define ADF_CSR_WR(csrAddr, csrOffset, val) \ > > >>> + rte_write32(val, (((uint8_t *)csrAddr) + csrOffset)) > > >> > > >> For IA, this update introduces an extra compiler barrier (rte_io_wmb= ()), > > >> which is indeed not a must, is this correct? > > > > > > AFAIK, Compiler barrier is required for IA. I am not an IA expert, if > > > someone thinks it needs to changed then I can fix it in following com= mit > > > in this patch series by making rte_io_wmb() and rte_io_rmb() as empty= . > > > > > > Let me know. > > > > I don't know, but what I know is this was working for IA without > > compiler barrier before. > > > > Bruce or Konstantin can help here. > > > I think having a compiler barrier is safer. If all data being written > before the actual register write to the device is volatile, none is > needed, but also in that case, the compiler barrier should have no > effect.=20 +1 >If some of the data is not volatile, then a barrier is needed > for correctness. IMHO, unless there is a performance regression by doing > so, I think having the IO register writes have compiler barriers on IA > is a good thing. It should save individual drivers from having to worry > about the barriers themselves in most cases. >=20 > Regards, > /Bruce