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 A8328A2EDB for ; Sun, 29 Sep 2019 13:51:40 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BCF2D2D13; Sun, 29 Sep 2019 13:51:39 +0200 (CEST) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 4CB012B88 for ; Sun, 29 Sep 2019 13:51:38 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us2.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 1D57A340067; Sun, 29 Sep 2019 11:51:37 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 29 Sep 2019 12:51:30 +0100 To: Shahaf Shuler , Adrien Mazarguil CC: simei , "qi.z.zhang@intel.com" , "jingjing.wu@intel.com" , "dev@dpdk.org" References: <1564030646-73951-1-git-send-email-simei.su@intel.com> <1564030646-73951-2-git-send-email-simei.su@intel.com> <291f410f-fc71-191b-8595-4c3d9e970041@solarflare.com> <20190731123040.GG4512@6wind.com> From: Andrew Rybchenko Message-ID: Date: Sun, 29 Sep 2019 14:51:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24942.002 X-TM-AS-Result: No-14.505500-8.000000-10 X-TMASE-MatchedRID: 1GZI+iG+MtfmLzc6AOD8DfHkpkyUphL9jQHi4chm1Ci1eX0jEQ9c6oYM M3r3suSe6Efa2in+vIuMTIcXG77ZtEnNJnifmrJ44h8r8l3l4ebqobkz1A0A7QytGucsJkSaaGR LCnKSipWpGGPHCY3d8KA+pByFvyaUiaGInQ1zYU0Fxov+3JYvY2m/mT16mTUCAVQmInValWTfF/ OnumK2EdC1ajSj65kQO5xTAS6tBIvSKNGAayk1lU95wQijrwBLfglgnB0nDhMRGC0rW8q1XbsnA PikIQ0UbJmQuqqJSM3c9Ou+u+Ia8c5kZpp05N1BNVRz+HwqL4IEa8g1x8eqFyoj1YGgtweJo8WM kQWv6iUD0yuKrQIMCAGLeSok4rrZC24oEZ6SpSkj80Za3RRg8C5JqEPDWBOSi7XrkPPV2nIQZPH 3dIy4065fxogKw3l3xfnl6ekLeGI= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--14.505500-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24942.002 X-MDID: 1569757897-lIMxumTRdPwl Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add symmetric toeplitz hash support 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" On 7/31/19 4:43 PM, Shahaf Shuler wrote: > Wednesday, July 31, 2019 3:31 PM, Adrien Mazarguil: >> Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add symmetric toeplitz hash >> support >> >> On Wed, Jul 31, 2019 at 03:08:19PM +0300, Andrew Rybchenko wrote: >>> On 7/25/19 7:57 AM, simei wrote: >>>> From: Simei Su >>>> >>>> Currently, there are DEFAULT,TOEPLITZ and SIMPLE_XOR hash funtion. >>>> To support symmetric hash by rte_flow RSS action, this patch adds >>>> new hash function "Symmetric Toeplitz" which is supported by some >> hardware. >>> Isn't it a question of key to achieve symmetry? >>> I.e. hash algorithm (function) is still the same - Toeplitz, but hash >>> key makes the result symmetric (i.e. equal for flows in both >>> directions - swap transport ports and IPv4/6 addresses). >> This is only an option when src/dst are known in advance. >> >> When doing RSS, HW implementations (such as Mellanox's) implement a >> modified Toeplitz XOR'ing src with dst resulting in the same hash both ways >> regardless of the key. > Just to stand correct it was a bug on Mellanox kernel driver that was fixed. Now the RSS is spec complaint (non-symmetric). > Andrew is correct one can have a special key that will make the RSS symmetric, however it is good to have this option for the user to explicitly request symmetric function (w/o any restriction on the key). I think we need a definition what is behind SYMMETRIC_TOEPLITZ here. If I'd like to test it and check, I need to know an algorithm in order to know what to expect. Also it is important to make it the same for all NIC vendors: what should algorithm be in order to say that it is symmetric Toeplitz?