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 5354E42359; Wed, 11 Oct 2023 04:11:50 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D8923402AE; Wed, 11 Oct 2023 04:11:49 +0200 (CEST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by mails.dpdk.org (Postfix) with ESMTP id F37A0400EF for ; Wed, 11 Oct 2023 04:11:47 +0200 (CEST) Received: from dggpeml100024.china.huawei.com (unknown [172.30.72.55]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4S4x4M6wYdzkY7Q; Wed, 11 Oct 2023 10:07:47 +0800 (CST) Received: from [10.67.121.161] (10.67.121.161) by dggpeml100024.china.huawei.com (7.185.36.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Wed, 11 Oct 2023 10:11:45 +0800 Subject: Re: [PATCH] ethdev: add calculate hash function To: Ferruh Yigit , Ori Kam , , Aman Singh , Yuying Zhang , Thomas Monjalon , Andrew Rybchenko CC: , References: <20230926113753.28765-1-orika@nvidia.com> <1ea4cca3-de4e-4495-ab32-abb88b71bf6d@amd.com> From: fengchengwen Message-ID: <04a3c2d3-4912-58f6-68d5-e93dcc1be768@huawei.com> Date: Wed, 11 Oct 2023 10:11:45 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <1ea4cca3-de4e-4495-ab32-abb88b71bf6d@amd.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.121.161] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpeml100024.china.huawei.com (7.185.36.115) X-CFilter-Loop: Reflected 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 Hi, On 2023/10/10 19:05, Ferruh Yigit wrote: > On 9/26/2023 12:37 PM, Ori Kam wrote: >> rte_flow supports insert by index table[1]. >> >> Using the above table, the application can create rules >> that are based on hash. >> For example application can create the following logic in order >> to create load balancing: >> 1. Create insert by index table with 2 rules, that hashes based on dmac >> 2. Insert to index 0 a rule that sends the traffic to port A. >> 3. Insert to index 1 a rule that sends the traffic to port B. >> >> Let's also assume that before this table, there is a 5 tuple >> match table that jumps to the above table. >> >> So each packet that matches one of the 5 tuple rules is RSSed >> to port A or B, based on dmac hash. >> >> The issue arises when there is a miss on the 5 tuple table, >> which resulted due to the packet being the first packet of this flow, or >> fragmented packet or any other reason. >> In this case, the application must calculate what would be the >> hash calculated by the HW so it can send the packet to the correct >> port. >> >> This new API allows applications to calculate the hash value of a given >> packet for a given table. >> >> [1] - http://patches.dpdk.org/project/dpdk/patch/20230208030624.78465-2-akozyrev@nvidia.com/ >> >> Signed-off-by: Ori Kam >> --- >> app/test-pmd/cmdline_flow.c | 86 +++++++++++++++++++++++++++++++++++- >> app/test-pmd/config.c | 54 ++++++++++++++++++++++ >> app/test-pmd/testpmd.h | 2 + >> lib/ethdev/rte_flow.c | 21 +++++++++ >> lib/ethdev/rte_flow.h | 32 ++++++++++++++ >> lib/ethdev/rte_flow_driver.h | 5 +++ >> lib/ethdev/version.map | 1 + >> 7 files changed, 200 insertions(+), 1 deletion(-) >> > > This is a new rte_flow API but unfortunately there isn't any > review/comment, at least it is experimental API. If there is no > objection/discussion in next few days, I will merge the feature. > > Probably it will be another rte flow feature that only NVIDIA knows and > uses. While mentioned from using, is the driver update for the feature The hns3 driver support subset of rte_flow, we found the rte_flow feature is very flexible. And its implementation varies according to vendors. Can the rte_flow be standardized ? > planned for this release? > > > Meanwhile, can you please update the documentation, `rte_flow.rst` and > `testpmd_funcs.rst`? > Also can you please rebase on top of latest next-net, this patch > conflicts with merged group set miss action feature. > > . >