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 07969A04FF; Thu, 24 Mar 2022 08:16:47 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CE172410FC; Thu, 24 Mar 2022 08:16:46 +0100 (CET) Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by mails.dpdk.org (Postfix) with ESMTP id B19B440141 for ; Thu, 24 Mar 2022 08:16:44 +0100 (CET) Received: by mail-pl1-f175.google.com with SMTP id x2so3836529plm.7 for ; Thu, 24 Mar 2022 00:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=K5bOmzEdJje4y7hhVnCjfY5ng47UI6bvihBES+ZvxEk=; b=FRM+vy2Jv6xra11RQ1RX/Hi2Dm9By2Vgi30RObqPTWbE2Sv2fbBa1flhsN7W8iM+2I LVEYCzsIX0mHA2i+VNHjqmnDuexc+INusxw9iPHinuSai9VDy4syNAwP0Ze/NzHNGjS+ Csfzgy9t07XH5P2YfDini3rwG2Zr4omQ48l1bGI1QcaKiKn6j6A2bVurqWBFvSA4Aya0 hp3965BneKqMjHh4SIWWTulvjFEC5IEm2Cszr71qRTa9TKYoaRr8MDdLdZ746FOT1Ce1 ksdXF3OaHR7NbtJbHdZUww5q/I15LEtrJYfbt6W3K5hEuz5ML+bv0I2HR+/D55aJvS8R bQ6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=K5bOmzEdJje4y7hhVnCjfY5ng47UI6bvihBES+ZvxEk=; b=D2KEJR2eadpZFDB9Edx2R63vvYJ1ykqUfjPzT114Fe2OvykEa4+tpy9PSHa/C3nkj0 WljlckfxOUybvkHHfJC0oOMyt2tO/aMMm2EfDolu/VCl+Q4A0NF7DXLsyPSwDAsc0ljr WZVr0Gmq7r9Y+UquokZ6oeFdZA79Tyv1Hcmhp0mXaN2ZyXjcX6gTkHfMVVNmagJMno5p 8PcTALqLW6VlLPSMcNBEs5W1Z+hh0SiJeurOT4N5nKCMpVC+I55G6PaKwo1gqDrIoTLe 6qZC4RJAG8Q4B6F/zXVXm1h7YeFhzOTgbr/skvp7fPgwxNVmSTBaoxWkVQ89bpRZNJ3n NVrA== X-Gm-Message-State: AOAM532Kno6H6talNp+Yd2byyCPBQDzHu8c2oIH7HZV7b7db/yJf+r7V NuuhMm696lilVQh4uKmQHzf+VYWSOQOckP75w+U= X-Google-Smtp-Source: ABdhPJwLO+N6BRBy4ineS6IfAU3c8b1JdN6eFwQdSMsm+oTWaLcOc38soVnuxmiCpxDCLzKYDMQgTsSbi40WH/mlObw= X-Received: by 2002:a17:903:18c:b0:154:9ee:cedc with SMTP id z12-20020a170903018c00b0015409eecedcmr4316671plg.123.1648106203893; Thu, 24 Mar 2022 00:16:43 -0700 (PDT) MIME-Version: 1.0 References: <20220228032146.37407-1-humin29@huawei.com> <5b829b45-220b-daa2-19e4-3b3fc746d152@huawei.com> <3844855.QkHrqEjB74@thomas> <20220302085919.4ec08fb5@hermes.local> In-Reply-To: <20220302085919.4ec08fb5@hermes.local> From: Harold Huang Date: Thu, 24 Mar 2022 15:16:32 +0800 Message-ID: Subject: Re: [PATCH 2/6] net/hns3: fix inconsistent enabled RSS behavior To: Stephen Hemminger , Thomas Monjalon , "lihuisong (C)" , Ferruh Yigit , "dev@dpdk.org" , Qi Zhang , Ori Kam Cc: "Min Hu (Connor)" , Andrew Rybchenko , Olivier Matz , Ajit Khaparde , "jerinj@marvell.com" , Slava Ovsiienko , huangdaode Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, all, On Thu, Mar 3, 2022 at 12:59 AM Stephen Hemminger wrote: > > On Wed, 02 Mar 2022 15:46:37 +0100 > Thomas Monjalon wrote: > > > 02/03/2022 15:07, Ori Kam: > > > From: lihuisong (C) > > > > =E5=9C=A8 2022/3/1 0:42, Ferruh Yigit =E5=86=99=E9=81=93: > > > > > On 2/28/2022 3:21 AM, Min Hu (Connor) wrote: > > > > >> From: Huisong Li > > > > >> > > > > >> RSS will not be enabled if the RTE_ETH_MQ_RX_RSS_FLAG isn't be s= et in > > > > >> dev_configure phase. However, if this flag isn't set, RSS can be= enabled > > > > >> through the ethdev ops and rte_flow API. This behavior is contra= ry to > > > > >> each > > > > >> other. > > > > >> > > > > >> Fixes: c37ca66f2b27 ("net/hns3: support RSS") > > > > >> Cc: stable@dpdk.org > > > > >> > > > > >> Signed-off-by: Huisong Li > > > > > > > > > > > > > > > Hi Huisong, Connor, > > > > > > > > > > Let's get a little more feedback for this patch, cc'ed more peopl= e. > > > > > > > > > > > > > > > To enable RSS, multi queue mode should be set to > > > > > 'RTE_ETH_MQ_RX_RSS_FLAG'. > > > > > > > > > > But I wonder if it is required to configure RSS via flow API, > > > > > > > > I do not know the original purpose of adding the RSS configuration = in > > > > flow API. In OVS-DPDK, there is a use case to add mark+rss action via flow API. See [= 1]: [1]: https://github.com/openvswitch/ovs/blob/master/lib/netdev-offload-dpdk= .c#L1677 > > > > > > > The purpose is simple, this allow to create RSS per rule and not a gl= obal one. > > > For example create RSS that sends TCP to some queues while othe RSS w= ill send > > > UDP traffic to different queues. > > > > > > > However, as far as I know, the hash algorithm can be configured via= this > > > > API, > > > > > > > > but not via ethdev ops API. > > > > > > > > > and if other PMDs check this configuration for flow API? > > > > > > > > Some PMDs already have similar check in RSS releated ops or rte_flo= w API. > > > > > > > > For example, hinic, axbge, bnxt, cnxk, otx2, and ena. > > > > I suggest removing these checks. > > > > > From my view point those are two different settings. > > > The RTE_ETH_MQ_RX_RSS_FLAG is global per port while > > > rte_flow is per rule. > > > > > > I think, that if a PMD needs this flag, in order to enable it also fo= r rte_flow then > > > it should be documented in the release note of the PMD. > > > It is a valid use case that the default traffic will not have RSS and= only rules created by > > > rte_flow will have the RSS, for matching traffc. > > > > I think RTE_ETH_MQ_RX_RSS_FLAG should not be required by any PMD > > for rte_flow RSS rules. > > > > > > Agreed. > > The ideal state around RSS would be: > - global settings affect the default started queues when device is sta= rted. > if RSS is enabled and 4 queues are started, then RSS would happen fo= r received > packets across those 4 queues. > - when adding new flow related rx: > - new queues could be started - BUT not part of original RSS > - new rte_flow rule can do RSS against the new flow: > example: > start queues 4,5,6,7 > rte_flow match TCP port 80 and process on queues 4,5,6,7 wi= th RSS > > This is a mess today, most devices work differently and there is no refer= ence software > implementation. In an ideal state, there would be a reference software i= mplementation > that implements all of rte_flow, and all new hardware support would have = to work the same > as the reference implementation. And there would be a full CI test suite = around rte_flow. When adding a new flow with RSS action, does the RSS hash type have to be set or it could inherit the global setting? I see there are some different behaviors when we use RSS actions without hash types. In my test, the E810 and Broadcom NetXtreme-E work well but there are some problems in MLX5. There is a patch in [2]. Anyone could give some suggestions? [2]: https://patchwork.ozlabs.org/project/openvswitch/patch/20220316080842.= 811478-1-baymaxhuang@gmail.com/ --=20 Thanks, Harold.