From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F5A4C433F5 for ; Wed, 2 Mar 2022 16:59:25 +0000 (UTC) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C507942715; Wed, 2 Mar 2022 17:59:24 +0100 (CET) Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by mails.dpdk.org (Postfix) with ESMTP id 6B0BE40141 for ; Wed, 2 Mar 2022 17:59:23 +0100 (CET) Received: by mail-pj1-f53.google.com with SMTP id m11-20020a17090a7f8b00b001beef6143a8so2342231pjl.4 for ; Wed, 02 Mar 2022 08:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=QYShjjFnD9qWnkxuy5H/onZBIi2n01x/PdgZzxQ90Ac=; b=beLRSgN0/rQDwNN8NwWWNHp0vWiJ+dUcQrC84EyDFGCuZzUh+MJtOEtrzRMbBvZbJU qHWATzDFX36vG7ZdMUv31Mg1EPvuSPkHEq8NNkXhwGI1T+eYqUjg2mNQn0G2EpsOnfhK 6b9V9hZU4/zMW4QPJJvQDoqy3DTKWtCBM2B0lvaojuZjhQy8CbRaTKy916x2hFzUjf93 CfUxiyo3GKtd7Env8uK8cd7vWeNHuw2Or7bM6aKIew9yFmG7LuiBTeDoWLcKf9rCn8G6 1WL5Pg+9qL6jpseyoav+dRS5LoVbw6ABZ8nZvMi7U3jneXRBDMGEk6tF54x1R2tDr0Jc 1vyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=QYShjjFnD9qWnkxuy5H/onZBIi2n01x/PdgZzxQ90Ac=; b=2PCqqPmB4DzofM3bQU/AG411c5qk5t7AdZZh+Elb6P1tk5cECrtOBlGVxz2xa3/rXC 3jAd78caS3+MAUY0mVypTxREOAXpR4tdkwVcvnR2LglSWFxf5sSuyDlqtcja5MOXJ52Z QZXPCaFZY+FbvOPQcU0mmHxwICTi80jK997F7Y/gHxqcAmcjWlCoqUjGbzxhrR39Gyq4 yLdlOGPUisn23GtfjjhO7Rkd0Qhg8PpU8h1OcSvgm85BdpYAMsrYzVb2YvwddYQsdSzs 6EWga0c92w6misj0PCyqVNZQ97u98zlF0/6TadO0Vc9i1QUty3zuZMgZi6kXOBroFgRD i9Rw== X-Gm-Message-State: AOAM532MvimU8iBCQoFTsnu/sNIvkR0ZU+N7wddFwo3Z6Peg49wGTLZB USs8D4uR6sCLbKI4VBUHBU9yPg== X-Google-Smtp-Source: ABdhPJwfmC4gpXEo/BApo3CfNqYph7qbTLK0eNICQBC3FPj9e3quGmvHZ7st7z1SEqIV/B8yiw2AIQ== X-Received: by 2002:a17:902:7296:b0:14f:2a67:b400 with SMTP id d22-20020a170902729600b0014f2a67b400mr32116291pll.172.1646240362457; Wed, 02 Mar 2022 08:59:22 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id t5-20020a17090ae50500b001bc4ec15949sm5634886pjy.2.2022.03.02.08.59.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Mar 2022 08:59:22 -0800 (PST) Date: Wed, 2 Mar 2022 08:59:19 -0800 From: Stephen Hemminger To: Thomas Monjalon Cc: "lihuisong (C)" , Ferruh Yigit , "Min Hu (Connor)" , "dev@dpdk.org" , Andrew Rybchenko , Qi Zhang , Ori Kam , Olivier Matz , Ajit Khaparde , "jerinj@marvell.com" , Slava Ovsiienko , huangdaode Subject: Re: [PATCH 2/6] net/hns3: fix inconsistent enabled RSS behavior Message-ID: <20220302085919.4ec08fb5@hermes.local> In-Reply-To: <3844855.QkHrqEjB74@thomas> References: <20220228032146.37407-1-humin29@huawei.com> <5b829b45-220b-daa2-19e4-3b3fc746d152@huawei.com> <3844855.QkHrqEjB74@thomas> MIME-Version: 1.0 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 On Wed, 02 Mar 2022 15:46:37 +0100 Thomas Monjalon wrote: > 02/03/2022 15:07, Ori Kam: > > From: lihuisong (C) =20 > > > =E5=9C=A8 2022/3/1 0:42, Ferruh Yigit =E5=86=99=E9=81=93: =20 > > > > On 2/28/2022 3:21 AM, Min Hu (Connor) wrote: =20 > > > >> From: Huisong Li > > > >> > > > >> RSS will not be enabled if the RTE_ETH_MQ_RX_RSS_FLAG isn't be set= in > > > >> dev_configure phase. However, if this flag isn't set, RSS can be e= nabled > > > >> through the ethdev ops and rte_flow API. This behavior is contrary= to > > > >> each > > > >> other. > > > >> > > > >> Fixes: c37ca66f2b27 ("net/hns3: support RSS") > > > >> Cc: stable@dpdk.org > > > >> > > > >> Signed-off-by: Huisong Li =20 > > > > > > > > > > > > Hi Huisong, Connor, > > > > > > > > Let's get a little more feedback for this patch, cc'ed more people. > > > > > > > > > > > > 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, =20 > > >=20 > > > I do not know the original purpose of adding the RSS configuration in > > > flow API. > > > =20 > > The purpose is simple, this allow to create RSS per rule and not a glob= al one. > > For example create RSS that sends TCP to some queues while othe RSS wil= l send > > UDP traffic to different queues. > > =20 > > > However, as far as I know, the hash algorithm can be configured via t= his > > > API, > > >=20 > > > but not via ethdev ops API. > > > =20 > > > > and if other PMDs check this configuration for flow API? =20 > > >=20 > > > Some PMDs already have similar check in RSS releated ops or rte_flow = API. > > >=20 > > > For example, hinic, axbge, bnxt, cnxk, otx2, and ena. =20 >=20 > I suggest removing these checks. >=20 > > 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. > >=20 > > I think, that if a PMD needs this flag, in order to enable it also for = 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 o= nly rules created by > > rte_flow will have the RSS, for matching traffc. =20 >=20 > I think RTE_ETH_MQ_RX_RSS_FLAG should not be required by any PMD > for rte_flow RSS rules. >=20 >=20 Agreed. The ideal state around RSS would be: - global settings affect the default started queues when device is start= ed. if RSS is enabled and 4 queues are started, then RSS would happen for = 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 with= RSS This is a mess today, most devices work differently and there is no referen= ce software implementation. In an ideal state, there would be a reference software imp= lementation 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 ar= ound rte_flow.