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 7670CA0524; Sun, 11 Apr 2021 20:51:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 61F18141423; Sun, 11 Apr 2021 20:51:57 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mails.dpdk.org (Postfix) with ESMTP id 686391413EF for ; Sun, 11 Apr 2021 20:51:56 +0200 (CEST) IronPort-SDR: vZDwzJidluU/mlVx7dzkwqNqdUbqMPJlJCM94uZR9udXJ0kLxO9Hp6ML2tkpSSKVUNCR8GAuvY a+UTL5dTh15Q== X-IronPort-AV: E=McAfee;i="6000,8403,9951"; a="279353416" X-IronPort-AV: E=Sophos;i="5.82,214,1613462400"; d="scan'208";a="279353416" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2021 11:51:55 -0700 IronPort-SDR: F634EgcYfF9OY66GyfBLD8ITv0uoyc/gbW0RHZGDxvOL6iPxd6Pmj0a5xNorcPzHz7M09A+nhA U7hXCRYtDplw== X-IronPort-AV: E=Sophos;i="5.82,214,1613462400"; d="scan'208";a="398117533" 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:51:52 -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-1-git-send-email-vladimir.medvedkin@intel.com> From: "Medvedkin, Vladimir" Message-ID: <493f8d8c-1797-d54b-ede7-547f04b388e7@intel.com> Date: Sun, 11 Apr 2021 21:51:50 +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 0/3] Predictable RSS feature 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" Hi Yipeng, Thanks for the review, On 10/04/2021 03:32, 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 0/3] Predictable RSS feature >> >> This patch series introduces predictable RSS feature. >> It is based on the idea of searching for partial hash collisions within Toeplitz >> hash. >> >> The Toeplitz hash function is a homomorphism between (G, ^) and (H, ^), >> where (G, ^) - is a group of tuples and (H, ^) is a group of hashes with respect >> to XOR operation. So tuples and hashes could be treated as n-dimension and >> 32-dimension vector spaces over GF(2). >> So, f(x ^ y) == f(x) ^ f(y) >> where f - is the toeplitz hash function and x, y are tuples. >> >> The ability to predict partial collisions allows user to compute input hash value >> with desired LSB values. >> Usually number of LSB's are defined by the size of RSS Redirection Table. >> >> There could be number of use cases, for example: >> 1) NAT. Using this library it is possible to select a new port number on a >> translation in the way that rss hash for original tuple will have the same LSB's >> as rss hash for reverse tuple. >> 2) IPSec/MPLS/Vxlan. It is possible to choose tunnel id to be pinned to a >> desired queue. >> 3) TCP stack. It is possible to choose a source port number for outgoing >> connections in the way that received replies will be assigned to desired >> queue. >> 4) RSS hash key generation. Hash key initialization with random values does >> not guarantee an uniform distribution amongst queues. This library uses >> mathematically proved algorithm to complete the rss hash key to provide the >> best distribution. >> >> v2: >> - added extra API rte_thash_adjust_tuple() >> - added extra tests for rte_thash_adjust_tuple() >> - added extra fields to rte_thash_subtuple_helper struct >> - fixed typos >> >> Vladimir Medvedkin (3): >> hash: add predictable RSS API >> hash: add predictable RSS implementation >> test/hash: add additional thash tests >> >> app/test/test_thash.c | 468 +++++++++++++++++++++++++++++++- >> lib/librte_hash/meson.build | 3 +- >> lib/librte_hash/rte_thash.c | 637 >> ++++++++++++++++++++++++++++++++++++++++++++ >> lib/librte_hash/rte_thash.h | 180 +++++++++++++ >> lib/librte_hash/version.map | 8 + >> 5 files changed, 1289 insertions(+), 7 deletions(-) create mode 100644 >> lib/librte_hash/rte_thash.c >> >> -- >> 2.7.4 > > [Wang, Yipeng] > Hi, Vladimir, thanks for the patch! > I haven't fully understood every bit of the algorithm yet, > but I did see issues that this patch could potentially solve. > My understanding is that there are some restrictions for the current implementation, > for example, it only supports port(16-bit) manipulation, but not multiple fields or IP. It supports any bit-range ( with size >= reta_sz, configured for the CTX) manipulations within a tuple as well as multiple number of them. > Still, I think it should be good for the use cases you listed. I would love to hear > more feedbacks from people who are more familiar with doing NAT in production systems. > > For me, besides the comments I sent earlier, > good documentation and references are needed with clear usage examples, as others pointed out already. > > Also, the current API design seems a bit cumbersome. > To use the library, one needs: > Init_ctx > Add_helper. > Get_helper > Get_complement > Then in a loop: > Adjust_tuples > Then XOR with the current tuple > > I wonder if an alternative all-in-one API could be designed for simpler use cases. Agree, v3 will have a new rte_thash_adjust_tuple() implementation that will make everything much easier. > > Thanks! > > > -- Regards, Vladimir