From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5621CA0524; Sun, 11 Apr 2021 20:52:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3F3DE141423; Sun, 11 Apr 2021 20:52:56 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id 4C2871413EF for ; Sun, 11 Apr 2021 20:52:54 +0200 (CEST) IronPort-SDR: 0tNxrE9B4hCSm7Uhx1oFN+PG0U8MMc30Yvoj1J1PDfIYb+70yQxbSw3OVyOCXotDFdzYJ7juZx 5l8cf0EBUwOA== X-IronPort-AV: E=McAfee;i="6000,8403,9951"; a="173547618" X-IronPort-AV: E=Sophos;i="5.82,214,1613462400"; d="scan'208";a="173547618" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2021 11:52:53 -0700 IronPort-SDR: iSuA7vnmEkiML8izImnNOsHLOturD44PRIoJFrP3YGR/pzhcRMW+wzt7Ch6fMgiJm9zAzENJng G2L/L/IH1d7A== X-IronPort-AV: E=Sophos;i="5.82,214,1613462400"; d="scan'208";a="398117634" Received: from vmedvedk-mobl.ger.corp.intel.com (HELO [10.252.4.10]) ([10.252.4.10]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2021 11:52:50 -0700 To: "Wang, Yipeng1" , "dev@dpdk.org" Cc: "Ananyev, Konstantin" , "Chilikin, Andrey" , "Kinsella, Ray" , "Gobriel, Sameh" , "Richardson, Bruce" , Stephen Hemminger References: <1615919077-77774-1-git-send-email-vladimir.medvedkin@intel.com> <1617738643-258635-3-git-send-email-vladimir.medvedkin@intel.com> From: "Medvedkin, Vladimir" Message-ID: <55e3ada5-4073-7e69-11d6-11366de565a9@intel.com> Date: Sun, 11 Apr 2021 21:52:49 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 2/3] hash: add predictable RSS implementation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" On 10/04/2021 03:10, Wang, Yipeng1 wrote: >> -----Original Message----- >> From: Medvedkin, Vladimir >> Sent: Tuesday, April 6, 2021 12:51 PM >> To: dev@dpdk.org >> Cc: Ananyev, Konstantin ; Chilikin, Andrey >> ; Kinsella, Ray ; Wang, >> Yipeng1 ; Gobriel, Sameh >> ; Richardson, Bruce >> >> Subject: [PATCH v2 2/3] hash: add predictable RSS implementation >> >> This patch implements predictable RSS functionality. >> >> Signed-off-by: Vladimir Medvedkin >> --- >> lib/librte_hash/rte_thash.c | 577 >> ++++++++++++++++++++++++++++++++++++++++++-- >> lib/librte_hash/rte_thash.h | 42 ++++ >> lib/librte_hash/version.map | 1 + >> 3 files changed, 602 insertions(+), 18 deletions(-) >> >> +/** >> + * writes m-sequence to the hash_key for range [start, end] >> + * (i.e. including start and end positions) */ static int >> +generate_subkey(struct rte_thash_ctx *ctx, struct thash_lfsr *lfsr, >> +uint32_t start, uint32_t end) >> +{ >> +uint32_t i; >> +uint32_t req_bits = (start < end) ? (end - start) : (start - end); >> +req_bits++; /* due to incuding end */ >> + >> +/* check if lfsr overflow period of the m-sequence */ >> +if (((lfsr->bits_cnt + req_bits) > (1ULL << lfsr->deg) - 1) && >> +((ctx->flags & >> RTE_THASH_IGNORE_PERIOD_OVERFLOW) != >> +RTE_THASH_IGNORE_PERIOD_OVERFLOW)) >> +return -ENOSPC; > [Wang, Yipeng] > If nospace, should one increase lfsr->deg? Or if it is already the highest deg you predefined then what to do? > Maybe a log msg could help user with more information on the solutions. It is not possible to increase the degree of lfsr due to mathematical restrictions. It must be exactly equal to the number of bits for which we want to have a collision. >> + >> +if (start < end) { >> +/* original direction (from left to right)*/ >> +for (i = start; i <= end; i++) >> +set_bit(ctx->hash_key, get_bit_lfsr(lfsr), i); >> +/** >> + * Adjust tuple with complimentary bits. >> + * > [Wang, Yipeng] > More explanation for this API is needed. > My understanding is that user should call this function in a loop, until > the above callback function returns success thus this function succeeds. I'm going to rewrite this function in v3. The loop will be internal. > BTW, why not put this API in the first API commit? > My fault, will fix this >> + * @param h >> + * Pointer to the helper struct >> + * @param orig_tuple >> + * Pointer to the tuple to be adjusted >> + * @param adj_bits >> + * Valure returned by rte_thash_get_compliment > [Wang, Yipeng] typo. *value >> + * @param fn >> + * Callback function to check adjusted tuple. Could be NULL >> + * @param userdata >> + * Pointer to the userdata to be passed to fn(). Could be NULL >> + * >> + * @return >> + * 0 on success >> + * negative otherwise >> + */ >> +__rte_experimental >> +int >> +rte_thash_adjust_tuple(struct rte_thash_subtuple_helper *h, >> +uint8_t *orig_tuple, uint32_t adj_bits, >> +rte_thash_check_tuple_t fn, void *userdata); >> + >> #ifdef __cplusplus >> } >> #endif >> diff --git a/lib/librte_hash/version.map b/lib/librte_hash/version.map index >> 93cb230..a992a1e 100644 >> --- a/lib/librte_hash/version.map >> +++ b/lib/librte_hash/version.map >> @@ -32,6 +32,7 @@ DPDK_21 { >> EXPERIMENTAL { >> global: >> >> +rte_thash_adjust_tuple; >> rte_hash_free_key_with_position; >> rte_hash_lookup_with_hash_bulk; >> rte_hash_lookup_with_hash_bulk_data; >> -- >> 2.7.4 > -- Regards, Vladimir