From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 378A843819; Thu, 4 Jan 2024 19:19:05 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 09182402CB; Thu, 4 Jan 2024 19:19:05 +0100 (CET) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id 17D154029A for <dev@dpdk.org>; Thu, 4 Jan 2024 19:19:03 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 58F5F3200B32; Thu, 4 Jan 2024 13:18:59 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 04 Jan 2024 13:19:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1704392338; x=1704478738; bh=VmqlGzdiT0tOLs3JslviuzdM8GBFeNBCx/2drTKB/Yc=; b= fRfcuBKaQS+E6pZBMJshpg9BhQSjPEz7Y1ih3f3uCha6SYBqvKVpuvyCGngRKVBY jhjMhcWOd2jE7AzG1Zi07EHfZgFtI9bp3FQwNeQEAjRDg5Ph27twObWO1XbXirDG 3zpShxhZn1ieVZ7IgO2AbIlI4PVuCoiLUzFz1IWoe7677Hig3IyNk37o0OKR3h8P ieTq0jPw4mlKkxdO8p8bag4R/iNBdH090mjEsY0C7IP3iFhdLFzMrjgfuefR8UP5 qXgKHttjjWk9UvypXQO6dz62VdWOJNmMfL6ONYfqGgI9Q+cZbgrFDnO58fK53qfm P8+I/T9lKgV4lGuqHC6H+g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704392338; x= 1704478738; bh=VmqlGzdiT0tOLs3JslviuzdM8GBFeNBCx/2drTKB/Yc=; b=f rK1Q7YLsQVEVb3769kgJQ0fomlnlO+btVvC+nYmx67bduV2hEKFG6x8n1EhzA6ln vLYwJYRluNyz5jjUkl50uU/voEM5KrBHvhhNsj1/UDrKzAz9+WZ+jMC5JzqY9Me4 9JmY7QOC/jhzS7jF8tVyoWzKf2RMl209etk1Y87ftr1nnBW/3lXNDm+biDk5cx6H DZOtRQMMpHO5WRRNW30VUI84U4SRtwfC3Td4A3ATCNgWGzOQOdopkzCE0ud4fI4e w83yB546tG29LdcTmrluTSOUqIuiwDApyNmy1LaJsRLGr4f5xJAPhMxUOS3HXZIe hLAQzS/B/pZhViuklJHIA== X-ME-Sender: <xms:kvaWZYJewnXNdItw78eUv5j5qUoTgo689PTAhiDrBhbQ9HDg7Ulucg> <xme:kvaWZYIleegGEeQhjG0EmqQFTypBfNjGbBlHSb9M53dBdfTlwB45AketpUwp2dPWW Ws3bNDz--zPFjO9jg> X-ME-Received: <xmr:kvaWZYscgBqhE6i-xayKXPUWVCWD_VTHiyNEEkpkZA2iyUeZyILPGyVcnzF00Zeis3Njo8mYfxIBz4NGnHscQ67QNw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdegjedgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddt ieekgfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: <xmx:kvaWZVZ1OIEwE_tTbinVsXn_hdCFhHHZO6s8hKXaJXr3WiOqNR8gqA> <xmx:kvaWZfb9ALptJRFbeSBgvrLI4I7pIxxT4bEQISpFJCQoZ_KkawE5gw> <xmx:kvaWZRDCRQpTvqCUVfjtlEyBbvXipzhziIN60WY59-SN80GQlhujBA> <xmx:kvaWZUNobKlk2yAm9b_5DqjEOoQhx7SUiP1kuWm0NRtjFkCz84_nXQ> Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 4 Jan 2024 13:18:56 -0500 (EST) From: Thomas Monjalon <thomas@monjalon.net> To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>, Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, Stephen Hemminger <stephen@networkplumber.org>, Ferruh Yigit <ferruh.yigit@amd.com>, Ori Kam <orika@nvidia.com> Cc: Dariusz Sosnowski <dsosnowski@nvidia.com>, "dev@dpdk.org" <dev@dpdk.org>, Raslan Darawsheh <rasland@nvidia.com> Subject: Re: [RFC] ethdev: introduce entropy calculation Date: Thu, 04 Jan 2024 19:18:54 +0100 Message-ID: <46066628.fMDQidcC6G@thomas> In-Reply-To: <MW2PR12MB46661638190E2BD97695695BD6672@MW2PR12MB4666.namprd12.prod.outlook.com> References: <20231210083100.7893-1-orika@nvidia.com> <DS0PR11MB7442607CB0F56C093D11F45EEB672@DS0PR11MB7442.namprd11.prod.outlook.com> <MW2PR12MB46661638190E2BD97695695BD6672@MW2PR12MB4666.namprd12.prod.outlook.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org 04/01/2024 15:33, Ori Kam: > Hi Cristian, > > > From: Dumitrescu, Cristian <cristian.dumitrescu@intel.com> > > Sent: Thursday, January 4, 2024 2:57 PM > > > > >> > > > > >> And unless this is specifically defined as 'entropy' in spec, I am too > > > > >> for rename. > > > > >> > > > > >> At least in VXLAN spec, it is mentioned that this field is to "enable a > > > > >> level of entropy", but not exactly names it as entropy. > > > > > > > > > > Exactly my thought about the naming. > > > > > Good to see I am not alone thinking this naming is disturbing :) > > > > > > > > I'd avoid usage of term "entropy" in this patch. It is very confusing. > > > > > > What about rte_flow_calc_encap_hash? > > > > > > > > How about simply rte_flow_calc_hash? My understanding is this is a general- > > purpose hash that is not limited to encapsulation work. > > Unfortunately, this is not a general-purpose hash. HW may implement a different hash for each use case. > also, the hash result is length differs depending on the feature and even the target field. > > We can take your naming idea and change the parameters a bit: > rte_flow_calc_hash(port, feature, *attribute, pattern, hash_len, *hash) > > For the feature we will have at this point: > NVGRE_HASH, > SPORT_HASH > > The attribute parameter will be empty for now, but it may be used later to add extra information > for the hash if more information is required, for example, some key. > In addition, we will also be able to merge the current function rte_flow_calc_table_hash, > if we pass the missing parameters (table id, template id) in the attribute field. > > What do you think? I like the idea of having a single function for HW hashes. Is there an impact on performance? How much is it sensitive?