From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 3992C1B18C for ; Sat, 29 Sep 2018 02:55:31 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2018 17:55:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,317,1534834800"; d="scan'208";a="266925835" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga005.fm.intel.com with ESMTP; 28 Sep 2018 17:55:14 -0700 Received: from fmsmsx117.amr.corp.intel.com (10.18.116.17) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 28 Sep 2018 17:55:15 -0700 Received: from fmsmsx151.amr.corp.intel.com ([169.254.7.87]) by fmsmsx117.amr.corp.intel.com ([169.254.3.34]) with mapi id 14.03.0319.002; Fri, 28 Sep 2018 17:55:14 -0700 From: "Wang, Yipeng1" To: Honnappa Nagarahalli , "Richardson, Bruce" CC: "dev@dpdk.org" , "michel@digirati.com.br" , "Gobriel, Sameh" Thread-Topic: [PATCH v2 7/7] hash: use partial-key hashing Thread-Index: AQHUUgpSAxEcwk/VE0m37zNHBAy4GKT85kYQgAmSlvA= Date: Sat, 29 Sep 2018 00:55:13 +0000 Message-ID: References: <1536253745-133104-1-git-send-email-yipeng1.wang@intel.com> <1537550255-252066-1-git-send-email-yipeng1.wang@intel.com> <1537550255-252066-8-git-send-email-yipeng1.wang@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNGUwNjQzM2QtOWRkZS00NTVlLTk2NWEtZWYwNmNlMDZlMGEyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQ1FZRFlcL05nRHhJcjJMXC8zcGIzQVRlN3VvYkttVzQrWGwxQ0ZIYkNjeVdLMnVTN2JMdzlcLytKRitqTDdlb1FFcSJ9 x-originating-ip: [10.1.200.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v2 7/7] hash: use partial-key hashing X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2018 00:55:31 -0000 >-----Original Message----- >From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com] >Sent: Wednesday, September 26, 2018 9:24 PM >To: Wang, Yipeng1 ; Richardson, Bruce >Cc: dev@dpdk.org; michel@digirati.com.br >Subject: RE: [PATCH v2 7/7] hash: use partial-key hashing > > >> +static inline void >> +get_buckets_index(const struct rte_hash *h, const hash_sig_t hash, >> +uint32_t *prim_bkt, uint32_t *sec_bkt, uint16_t *sig) { >> +/* >> + * We use higher 16 bits of hash as the signature value stored in table= . >> + * We use the lower bits for the primary bucket >> + * location. Then we XOR primary bucket location and the signature >> + * to get the secondary bucket location. This is same as >> + * proposed in Bin Fan, et al's paper >> + * "MemC3: Compact and Concurrent MemCache with Dumber >> Caching and >> + * Smarter Hashing". The benefit to use >> + * XOR is that one could derive the alternative bucket location >> + * by only using the current bucket location and the signature. >> + */ >> +*sig =3D hash >> 16; >> + >> +*prim_bkt =3D hash & h->bucket_bitmask; >> +*sec_bkt =3D (*prim_bkt ^ *sig) & h->bucket_bitmask; } >> + >IMO, this function can be split into 2 - one for primary bucket index and = another for secondary bucket index. The secondary bucket >index calculation function can be used in functions ' rte_hash_cuckoo_move= _insert_mw' and ' rte_hash_cuckoo_make_space_mw'. > [Wang, Yipeng] I agree that breaking them down and use function call instea= d of explicit code will be easier for future extension, i.e. changing the algorithm, etc.=20 I split the function into 3 in V4. Please check out. >> -/** Signature of key that is stored internally. */ >> +/** >> + * A hash value that is used to generate signature stored in table and >> +the >> + * location the signature is stored. >> + */ >This is an external file. This documentation goes into the API guide. IMO,= we should change the comment to help the user. How about >changing this to 'hash value of the key'? > [Wang, Yipeng] Improved in V4. Please check! Thanks!