From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id EC6FDA057C; Thu, 26 Mar 2020 15:16:47 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B8AB42C15; Thu, 26 Mar 2020 15:16:47 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 56349F3E for ; Thu, 26 Mar 2020 15:16:46 +0100 (CET) IronPort-SDR: 1PTGDrm3ceuX4Nyas3EKdqjRoqDCitr8S3jyMY9sSBAJd8gj+eGMmS0nrt1+rrK7c753NMlELv 0CmKy+37PVcw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Mar 2020 07:16:44 -0700 IronPort-SDR: O4B+AvgsWsSQ496qmUmCHzoPuMZM6rKD8qb7lki9AAqhv+w0hYWmlr6sbGLTulIUstYHnt4H3w ezZxNLoecX4Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,308,1580803200"; d="scan'208";a="236289198" Received: from vmedvedk-mobl.ger.corp.intel.com (HELO [10.252.26.53]) ([10.252.26.53]) by orsmga007.jf.intel.com with ESMTP; 26 Mar 2020 07:16:41 -0700 To: "Wang, Yipeng1" , "dev@dpdk.org" Cc: "Gobriel, Sameh" , "Richardson, Bruce" References: <1583757860-375294-1-git-send-email-vladimir.medvedkin@intel.com> From: "Medvedkin, Vladimir" Message-ID: <56de1f61-7e13-83f1-6522-3a5c6778b8d8@intel.com> Date: Thu, 26 Mar 2020 14:16:40 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH 1/2] hash: add hash bulk lookup with hash signatures array 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Yipeng, On 17/03/2020 17:27, Wang, Yipeng1 wrote: >> -----Original Message----- >> From: Medvedkin, Vladimir >> Sent: Monday, March 9, 2020 5:44 AM >> To: dev@dpdk.org >> Cc: Wang, Yipeng1 ; Gobriel, Sameh >> ; Richardson, Bruce >> >> Subject: [PATCH 1/2] hash: add hash bulk lookup with hash signatures array >> >> Implement rte_hash_lookup_with_hash_bulk_data() - lookup function with >> precomputed hash signatures. >> >> Signed-off-by: Vladimir Medvedkin >> --- >> --- a/lib/librte_hash/rte_hash.h >> +++ b/lib/librte_hash/rte_hash.h >> @@ -528,6 +528,33 @@ rte_hash_lookup_bulk_data(const struct rte_hash >> *h, const void **keys, >> * Hash table to look in. >> * @param keys >> * A pointer to a list of keys to look for. >> + * @param sig >> + * A pointer to a list of precomputed hash values for keys. >> + * @param num_keys >> + * How many keys are in the keys list (less than >> RTE_HASH_LOOKUP_BULK_MAX). >> + * @param hit_mask >> + * Output containing a bitmask with all successful lookups. >> + * @param data >> + * Output containing array of data returned from all the successful lookups. >> + * @return >> + * -EINVAL if there's an error, otherwise number of successful lookups. >> + */ >> +__rte_experimental >> +int >> +rte_hash_lookup_with_hash_bulk_data(const struct rte_hash *h, >> + const void **keys, hash_sig_t *prim_hash, > [Wang, Yipeng] hash_sig_t *sig >> + uint32_t num_keys, uint64_t *hit_mask, void *data[]); >> + >> +/** >> + * Find multiple keys in the hash table. > [Wang, Yipeng] ...with precomputed hash value array. >> + * This operation is multi-thread safe with regarding to other lookup threads. >> + * Read-write concurrency can be enabled by setting flag during >> + * table creation. >> + * > [Wang, Yipeng] > Hi, Vladimir, thanks for the patch! > > Besides the minor comments above, my major concern is the code duplication here. > It is after all hundred's lines of code that in future if we want to extend features, we need > to modify both function blocks. > > Have you tried to just do if-else and reuse the current code block, and measure the performance? > If that causes performance difference, then we may justify adding the duplication, but we still > Need to optimize the software pipelining accordingly. Agree, I'll get rid of code duplication in v2. > -- Regards, Vladimir