From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 957799360 for ; Thu, 8 Sep 2016 11:40:43 +0200 (CEST) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga104.fm.intel.com with ESMTP; 08 Sep 2016 02:40:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,300,1470726000"; d="scan'208";a="5952069" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by fmsmga006.fm.intel.com with ESMTP; 08 Sep 2016 02:40:41 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.71]) by IRSMSX152.ger.corp.intel.com ([169.254.6.43]) with mapi id 14.03.0248.002; Thu, 8 Sep 2016 10:40:40 +0100 From: "Dumitrescu, Cristian" To: Thomas Monjalon , Gowrishankar Muthukrishnan CC: "dev@dpdk.org" , Chao Zhu , "Richardson, Bruce" , "Ananyev, Konstantin" , Pradeep Thread-Topic: [dpdk-dev] [PATCH v6 9/9] table: align rte table hash structs for cache line size Thread-Index: AQHR96j6GxoeAj4fkk6+6IE8qxZgAqBjZAtAgAwEzICAABHNEA== Date: Thu, 8 Sep 2016 09:40:39 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D8912647A669E2@IRSMSX108.ger.corp.intel.com> References: <1471343279-24014-1-git-send-email-gowrishankar.m@linux.vnet.ibm.com> <1471343279-24014-10-git-send-email-gowrishankar.m@linux.vnet.ibm.com> <3EB4FA525960D640B5BDFFD6A3D8912647A547BE@IRSMSX108.ger.corp.intel.com> <7893708.49gP68faKh@xps13> In-Reply-To: <7893708.49gP68faKh@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTNiN2M4MmQtZTU3Ni00OWJiLTkyMzgtYWIyZTJmNjU1MTU1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Im45akhRUmt5OXFWVDQ2THJNNm5UTUlHdFhsMEZIaEpySm5mZ3Z3dmFzdkk9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v6 9/9] table: align rte table hash structs for cache line size 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: Thu, 08 Sep 2016 09:40:44 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Thursday, September 8, 2016 10:36 AM > To: Gowrishankar Muthukrishnan > Cc: dev@dpdk.org; Dumitrescu, Cristian ; > Chao Zhu ; Richardson, Bruce > ; Ananyev, Konstantin > ; Pradeep > Subject: Re: [dpdk-dev] [PATCH v6 9/9] table: align rte table hash struct= s for > cache line size >=20 > 2016-08-31 17:29, Dumitrescu, Cristian: > > From: Gowrishankar Muthukrishnan > > > rte table hash structs rte_bucket_4_8, rte_bucket_4_16 and > > > rte_bucket_4_32 have > > > to be cache aligned as required by their corresponding hash create > functions > > > rte_table_hash_create_key8_lru etc. > > > > Hi Gowrishankar, > > > > My understanding is you are trying to work around the check invoked by > the hash table create functions that verifies the size of the bucket head= er > structure is a multiple of the cache line, right? > > > > Given that the size of this structure is 1x, 2x or 3x times 64 bytes, t= he check > passes on IA CPUs (cache line of 64 bytes; explicit alignment to cache li= ne size > is not needed in order to make the size of the structure a multiple of ca= che > line), but not on PPC CPUs (cache line of 128 bytes), correct? > > > > I don't think your proposal provides the best way to fix this issue, si= nce > your code leads to a considerable increase in the memory consumption used > per bucket in most cases: > > - 100% more memory for 8-byte key hash table > > - 0% more for 16-byte key hash table (code does not fix anything, > explicit alignment is not needed) > > - 50% more for 32-byte key hash table > > > > I suggest you simply change the check: instead of validating this data > structure is a multiple of cache line size, validate it is a multiple of = 64 bytes. >=20 > Any news please? > The whole series is blocked for this patch. > Should we expect a v7? Yes, I think we should. Small fix for a considerable benefit.