From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id 72483952 for ; Thu, 8 Sep 2016 11:36:25 +0200 (CEST) Received: by mail-wm0-f46.google.com with SMTP id w12so24694239wmf.0 for ; Thu, 08 Sep 2016 02:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=OpRKdVkji11XGb8KdNlOApQADnieuuY42lptBT/Dc/k=; b=q3K+v8Mjk3sI4BxRpbBMZAsjpsYZpIHwcV+JnFKnYtSzZJSzRDg/fK0yUOsyr0wsCA SRZoigc9kEzIXCKdJGM2W6r6+NjuUDx+VMtzzPQvW2qTAZExjAnp2oZ9TkwHiw+hYn+m Rfoo/KXmp74Z14WGiZ/bUO5/OnoKYK7DKNwgpxP+yCF2+ExFwJmiSehVyVuRS8NonrDm NEUi2Nc7CD3SVVqbFzHt8tlZuwPSLbj4D8MbLRRGtNdHNfdcOxciont8ihX+U4TR+ybs V5TNlTIWyZtrsKId/oe788FaABYe8MtKM8un8BtPuEa24lNqVbAY/kvUZ5WnkaoxYGYi 0zdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=OpRKdVkji11XGb8KdNlOApQADnieuuY42lptBT/Dc/k=; b=CnmEDk9Y2YYJWi7V/eXXx+mOLZf9RqvdSKznLzbLVsDrmRnBsokr7tg9OxbT6218eO Tdoajsc9WR7b1CGbjcSv6zU16HrNP6WB5OUUEptgyeLp+vvfkNkK4v3Ut2+JuZuv6Msy Ob7QOmTWwP6R8VhCOZnGRDr42Wrzmw+FPWUJjfglkI9J7ZZq1N5ZJtm0ErWvI0t5TLer wtO1pyKxbYZv7xhqKazWgEAJsoQyVVYvD6zuXarbCETtLvPSCc+2F+h3aHQ8D917KJRo Jsa8U9MxTusOIwFefk3LL3ngmp97LbetyuIATfaidmzjK3SRk7O5TBO2WeZ04E9somA0 ZI2w== X-Gm-Message-State: AE9vXwOySLGk8abegZBSnnPSo3xjY2iFi8AVlduDrgdVzWOWYi3QSsSSx5hvC/Ly5xXK2WuL X-Received: by 10.28.184.19 with SMTP id i19mr7774507wmf.43.1473327385216; Thu, 08 Sep 2016 02:36:25 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id r6sm8660737wme.6.2016.09.08.02.36.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 02:36:23 -0700 (PDT) From: Thomas Monjalon To: Gowrishankar Muthukrishnan Cc: dev@dpdk.org, "Dumitrescu, Cristian" , Chao Zhu , "Richardson, Bruce" , "Ananyev, Konstantin" , Pradeep Date: Thu, 08 Sep 2016 11:36:23 +0200 Message-ID: <7893708.49gP68faKh@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D8912647A547BE@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> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:36:25 -0000 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?