From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 3A09E2B93 for ; Wed, 28 Sep 2016 11:02:44 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP; 28 Sep 2016 02:02:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,409,1470726000"; d="scan'208";a="14538439" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.220.108]) by orsmga004.jf.intel.com with SMTP; 28 Sep 2016 02:02:41 -0700 Received: by (sSMTP sendmail emulation); Wed, 28 Sep 2016 10:02:40 +0025 Date: Wed, 28 Sep 2016 10:02:40 +0100 From: Bruce Richardson To: Pablo de Lara Cc: dev@dpdk.org Message-ID: <20160928090240.GA47356@bricha3-MOBL3> References: <1472856999-31028-1-git-send-email-pablo.de.lara.guarch@intel.com> <1473190444-120795-1-git-send-email-pablo.de.lara.guarch@intel.com> <1473190444-120795-2-git-send-email-pablo.de.lara.guarch@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1473190444-120795-2-git-send-email-pablo.de.lara.guarch@intel.com> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH v3 1/4] hash: reorder hash structure 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: Wed, 28 Sep 2016 09:02:44 -0000 On Tue, Sep 06, 2016 at 08:34:01PM +0100, Pablo de Lara wrote: > In order to optimize lookup performance, hash structure > is reordered, so all fields used for lookup will be > in the first cache line. > > Signed-off-by: Pablo de Lara > --- > lib/librte_hash/rte_cuckoo_hash.h | 12 +++++++----- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/lib/librte_hash/rte_cuckoo_hash.h b/lib/librte_hash/rte_cuckoo_hash.h > index e290dab..701531a 100644 > --- a/lib/librte_hash/rte_cuckoo_hash.h > +++ b/lib/librte_hash/rte_cuckoo_hash.h > @@ -182,9 +182,7 @@ struct rte_hash_bucket { > > /** A hash table structure. */ > struct rte_hash { > - char name[RTE_HASH_NAMESIZE]; /**< Name of the hash. */ > - uint32_t entries; /**< Total table entries. */ > - uint32_t num_buckets; /**< Number of buckets in table. */ > + /* first cache line - fields used in lookup */ > uint32_t key_len; /**< Length of hash key. */ > rte_hash_function hash_func; /**< Function used to calculate hash. */ > uint32_t hash_func_init_val; /**< Init value used by hash_func. */ > @@ -196,12 +194,13 @@ struct rte_hash { > from hash signature. */ > uint32_t key_entry_size; /**< Size of each key entry. */ > > - struct rte_ring *free_slots; /**< Ring that stores all indexes > - of the free slots in the key table */ > void *key_store; /**< Table storing all keys and data */ > struct rte_hash_bucket *buckets; /**< Table with buckets storing all the > hash values and key indexes > to the key table*/ > + > + struct rte_ring *free_slots; /**< Ring that stores all indexes > + of the free slots in the key table */ > uint8_t hw_trans_mem_support; /**< Hardware transactional > memory support */ > struct lcore_cache *local_free_slots; > @@ -209,6 +208,9 @@ struct rte_hash { > enum add_key_case add_key; /**< Multi-writer hash add behavior */ > > rte_spinlock_t *multiwriter_lock; /**< Multi-writer spinlock for w/o TM */ > + char name[RTE_HASH_NAMESIZE]; /**< Name of the hash. */ > + uint32_t entries; /**< Total table entries. */ > + uint32_t num_buckets; /**< Number of buckets in table. */ Hi Pablo, While I've no strong objection to the change, having the name at the start is a common paradigm in DPDK. Rather than place these fields at the end, can you get the same effect by just marking the key_len function __rte_cache_aligned? It may use a little more memory per table, but given that the size of the hash table is going to be largely governed by the table data, I don't see an extra 64 bytes in the structure as being an issue. Regards, /Bruce