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 29B37A0524; Sun, 11 Apr 2021 20:51:25 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0E0B9141429; Sun, 11 Apr 2021 20:51:25 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mails.dpdk.org (Postfix) with ESMTP id 118DC1413EA for ; Sun, 11 Apr 2021 20:51:22 +0200 (CEST) IronPort-SDR: /Zljt914v+2hpZTKlYsofxEChXLva6E73qAFaoWzZq44n1TfmwwAAs63UudtaAUQ8dDCzqMvr/ EGTquxVnFDrA== X-IronPort-AV: E=McAfee;i="6000,8403,9951"; a="255385424" X-IronPort-AV: E=Sophos;i="5.82,214,1613462400"; d="scan'208";a="255385424" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2021 11:51:21 -0700 IronPort-SDR: Q3Fy/8z03zy71yhWks9OtK6h7UCXpTv9wd+f+OLDhVMSA9cBDs+FWClnmwsLVgTDIb0PMlEq2t mRL/sqejiDTg== X-IronPort-AV: E=Sophos;i="5.82,214,1613462400"; d="scan'208";a="398117477" 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:19 -0700 To: Stephen Hemminger Cc: dev@dpdk.org, konstantin.ananyev@intel.com, andrey.chilikin@intel.com, ray.kinsella@intel.com, yipeng1.wang@intel.com, sameh.gobriel@intel.com, bruce.richardson@intel.com References: <1615919077-77774-1-git-send-email-vladimir.medvedkin@intel.com> <1617738643-258635-1-git-send-email-vladimir.medvedkin@intel.com> <20210408085604.7af44b12@hermes.local> From: "Medvedkin, Vladimir" Message-ID: <2e137eb7-2a85-50ef-01c8-00a633a1a3d5@intel.com> Date: Sun, 11 Apr 2021 21:51:17 +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: <20210408085604.7af44b12@hermes.local> 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 Stephen, Thanks for the feedback, On 08/04/2021 18:56, Stephen Hemminger wrote: > On Tue, 6 Apr 2021 20:50:40 +0100 > Vladimir Medvedkin wrote: > >> 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 >> > > It would be good to show how this could be used in an application. > Maybe yet another variant/flag to l3fwd example. Agree, I think it would be great to have a simple NAT implementation in examples. We've discussed this and will probably add in next releases. > -- Regards, Vladimir