From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 973D95A68 for ; Fri, 10 Jul 2015 12:39:37 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP; 10 Jul 2015 03:39:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,446,1432623600"; d="scan'208";a="759740745" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.63]) by fmsmga002.fm.intel.com with SMTP; 10 Jul 2015 03:39:33 -0700 Received: by (sSMTP sendmail emulation); Fri, 10 Jul 2015 11:39:32 +0025 Date: Fri, 10 Jul 2015 11:39:32 +0100 From: Bruce Richardson To: "De Lara Guarch, Pablo" Message-ID: <20150710103932.GC10556@bricha3-MOBL3> References: <1433514804-7075-1-git-send-email-pablo.de.lara.guarch@intel.com> <1435269919-7007-1-git-send-email-pablo.de.lara.guarch@intel.com> <1435269919-7007-9-git-send-email-pablo.de.lara.guarch@intel.com> <20150626094955.4a999f79@urahara> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v2 08/11] hash: add new functionality to store data in hash table 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: Fri, 10 Jul 2015 10:39:38 -0000 On Sun, Jun 28, 2015 at 10:23:28PM +0000, De Lara Guarch, Pablo wrote: > Hi Stephen, > > > -----Original Message----- > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > Sent: Friday, June 26, 2015 5:50 PM > > To: De Lara Guarch, Pablo > > Cc: dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v2 08/11] hash: add new functionality to > > store data in hash table > > > > We did same thing with a slightly different method. > > > > Subject: rte_hash: split key and bucket size > > > > It is useful to store more data in the has bucket than just the key size. > > For example, storing an addresss and additional data. > > > > Signed-off-by: Stephen Hemminger > > Did you send this patch? I did not see it in the mailing list... > Anyway, I like the idea of allowing the user to store variable size data (I was storing 8-byte data). > So I have sent a v3 with a more similar method, although I still use the new functions, > and use the parameter data_len for knowing the amount of bytes of data, and I keep constant the input key, > and return the data in another parameter. > > Thanks for it! > Pablo Hi Pablo, Stephen, having looked at the V3, having an arbitrary length of data stored in the hash table doesn't seem right to me. Since the original versions of this we have support for storing an 8-byte pointer in the hash table to be returned to the user on lookup, and I believe this provides the best option from an implementation and usability perspective. For cases where the data to be stored is fairly large, for example, 16/32 bytes or more, storing that in the hash table is going to waste a lot of space, and having the data stored outside the table is probably a better option, with a table lookup returning a pointer. We can even have the table lookup prefetch the pointer. It also allows multiple hash table lookups to point to the same external piece of data. For storing integer values, e.g. indexes into an external table, those can be stored as uintptr_t types in place of the pointer itself. Regards, /Bruce