From mboxrd@z Thu Jan 1 00:00:00 1970 From: gowrishankar muthukrishnan Subject: Re: [PATCH v6 9/9] table: align rte table hash structs for cache line size Date: Thu, 8 Sep 2016 22:22:17 +0530 Message-ID: <0ae24536-c04c-dcf2-5cd9-cb4904a47bb0@linux.vnet.ibm.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> <3EB4FA525960D640B5BDFFD6A3D8912647A669E2@IRSMSX108.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" , Chao Zhu , "Richardson, Bruce" , "Ananyev, Konstantin" , Pradeep To: "Dumitrescu, Cristian" , Thomas Monjalon Return-path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by dpdk.org (Postfix) with ESMTP id 91084374F for ; Thu, 8 Sep 2016 18:52:33 +0200 (CEST) Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u88Glwjq118761 for ; Thu, 8 Sep 2016 12:52:32 -0400 Received: from e23smtp05.au.ibm.com (e23smtp05.au.ibm.com [202.81.31.147]) by mx0a-001b2d01.pphosted.com with ESMTP id 25b2qvprk8-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 08 Sep 2016 12:52:32 -0400 Received: from localhost by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 9 Sep 2016 02:52:27 +1000 Received: from d23relay09.au.ibm.com (d23relay09.au.ibm.com [9.185.63.181]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id C7BE32BB005A for ; Fri, 9 Sep 2016 02:52:20 +1000 (EST) Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay09.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u88GqK9264028778 for ; Fri, 9 Sep 2016 02:52:20 +1000 Received: from d23av02.au.ibm.com (localhost [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u88GqKfY013263 for ; Fri, 9 Sep 2016 02:52:20 +1000 In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D8912647A669E2@IRSMSX108.ger.corp.intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Thanks Cristian and Thomas for your feedback. I have taken your suggestions and sent out v7. Please check if the new patch is fine. Thanks, Gowrishankar On Thursday 08 September 2016 03:10 PM, Dumitrescu, Cristian wrote: > >> -----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 structs for >> cache line size >> >> 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 header >> structure is a multiple of the cache line, right? >>> Given that the size of this structure is 1x, 2x or 3x times 64 bytes, the check >> passes on IA CPUs (cache line of 64 bytes; explicit alignment to cache line size >> is not needed in order to make the size of the structure a multiple of cache >> 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, since >> 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. >> >> 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. > >