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 8871AA0506; Wed, 23 Mar 2022 20:04:29 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 278FD427F6; Wed, 23 Mar 2022 20:04:29 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 2278A4068A for ; Wed, 23 Mar 2022 20:04:28 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6277E5C032D; Wed, 23 Mar 2022 15:04:26 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 23 Mar 2022 15:04:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; bh=e6NVLj7agwJj+L 0zb0+3AHqyaI58TOdVpxhDRJxYJ5g=; b=f5LPtbZbx98ugzD8mYoPZnLwoQPk53 NTdT+K+ay2cFUwmabBuIPv1a5f72xC1P7BVVmVUMfzEplEq9wfaZRNagDo/lkRMO NP/wGvDetyvKDEhlnyZ6S8KNAu6KTXoi78vV+hgOR51jBe2dlv/tRqsSrugxBlrf laGmMUIMDwuZ/ylLsbzIrQu/+soJ0a5/7R8HxQKE4aBaQXAtluipBpqc/zi2DXAn zjgBvT9wqGaOlSyMTVYzdEDVK3QnmLaJE6eq1Q613RQ50R6M4hPvi8WXYxVVfeAG +kl6IDjJ20tT+WHc5VrVe9Lhl7FXeyE3YheH2qDNXCPwbqtyZmiVYq4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=e6NVLj7agwJj+L0zb0+3AHqyaI58TOdVpxhDRJxYJ 5g=; b=Nz2+EPc9sRmjJtZIuzLePjbXYU1frbwg+U0iLT5lu+goan2xz7EvoGO9Z K+OLDZc5TztFu9MkYsIAPH9AIcGwxLROx/TlOMjXtgbh0jz1ADvFVh8IR6U7Fi+B 5AUZ37sH+S1aVdRb0Fs1jXWzzov5XcWK3Hc7qgztHQTun7dGHgDV9xXfMaDGXV+t AyU2B2eFGNAHYMWXhTKKwzGv4Sq3ZfYShhjxlKFmH6+av2u83lLOeAIgKbZTlVCB 09uNKCPt5kGioplqczRvKwimYgOyMUAMOfendDxZXZai3ILhI7d0OEoX/1Ivj4Rm OvvuBjBo7FL9q6hHiKWux/TsqmKUA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudegjedguddvtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeekteehtdeivefhieegjeelgedufeejheekkeetueevieeuvdev uedtjeevheevteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 23 Mar 2022 15:04:23 -0400 (EDT) From: Thomas Monjalon To: "Min Hu (Connor)" , "lihuisong (C)" Cc: Ori Kam , "dev@dpdk.org" , Andrew Rybchenko , Qi Zhang , Olivier Matz , Ajit Khaparde , "jerinj@marvell.com" , Stephen Hemminger , Slava Ovsiienko , huangdaode Subject: Re: [PATCH 2/6] net/hns3: fix inconsistent enabled RSS behavior Date: Wed, 23 Mar 2022 20:04:21 +0100 Message-ID: <109872978.nniJfEyVGO@thomas> In-Reply-To: <90f30b34-e376-3782-87fd-1ebbf330a3d6@huawei.com> References: <20220228032146.37407-1-humin29@huawei.com> <1785739.atdPhlSkOF@thomas> <90f30b34-e376-3782-87fd-1ebbf330a3d6@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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 23/03/2022 12:04, lihuisong (C): > =E5=9C=A8 2022/3/23 17:14, Thomas Monjalon =E5=86=99=E9=81=93: > > 23/03/2022 04:05, lihuisong (C): > >> =E5=9C=A8 2022/3/23 1:13, Thomas Monjalon =E5=86=99=E9=81=93: > >>> 21/03/2022 08:14, lihuisong (C): > >>>> 2022/3/10 16:08, lihuisong (C): > >>>>> 2022/3/9 17:55, Ori Kam: > >>>>>> From: lihuisong (C) > >>>>>>> 2022/3/3 10:47, lihuisong (C): > >>>>>>>> 2022/3/2 22:07, Ori Kam: > >>>>>>>>> From: lihuisong (C) > >>>>>>>>>> 2022/3/1 0:42, Ferruh Yigit: > >>>>>>>>>>> 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 > >>>>>>>>>>>> set in > >>>>>>>>>>>> dev_configure phase. However, if this flag isn't set, RSS ca= n be > >>>>>>>>>>>> enabled > >>>>>>>>>>>> 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 > >>>>>>>>>>> Hi Huisong, Connor, > >>>>>>>>>>> > >>>>>>>>>>> Let's get a little more feedback for this patch, cc'ed more p= eople. > >>>>>>>>>>> > >>>>>>>>>>> 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. > >>>>>>>>>> > >>>>>>>>> The purpose is simple, this allow to create RSS per rule and no= t a > >>>>>>>>> global one. > >>>>>>>>> For example create RSS that sends TCP to some queues while othe= RSS > >>>>>>>>> will send > >>>>>>>>> UDP traffic to different queues. > >>>>>>>> I'm a little confused now. The "per rule" also seems to be a glo= bal > >>>>>>>> configuration. > >>>>>>>> Example: > >>>>>>>> - start PMD with 0,1,2,3 > >>>>>>>> - create TCP packets to 2,3 queues. At this moment, only 2,3= queues > >>>>>>>> can be received for other types of packets. > >>>>>>>> Because this rule is implemented by modifying the entry of the > >>>>>>>> redirection table which is global for this device. > >>>>>>> Hi, Ori and Stephen. > >>>>>>> Can you help me clear up the confusion above? If some NICs behave= like > >>>>>>> this, what should we do about it? > >>>>>> I'm not sure I understand the issue, maybe it is releated to some > >>>>>> HW/PMD limitation. > >>>>>> In your example non TCP traffic will be routed to one of the 4 que= ues > >>>>>> (0,1,2,3), > >>>>>> While TCP traffic will only be routed to queues 2,3. > >>>>>> > >>>>>> Now I can add new rule that matches on UDP packet and RSS to queue= 0 > >>>>>> and 3 in this case: > >>>>>> TCP packets will be routed to queues 0,3. > >>>>>> UDP packets will be routed to queues 2,3. > >>>>>> All the rest of the traffic will be routed to queues 0,1,2,3 > >>>>>> > >>>>>> And just to be clear if now I add a rule to match all packets in > >>>>>> higher priority, > >>>>>> with RSS to queues 1,2. Then all traffic will be routed to queues = 1,2. > >>>>>> > >>>>>> At least this is what is expected, from API point of view. > >>>>>> > >>>>>> Best, > >>>>>> Ori > >>>>> Thank you for your answer. I understand it. > >>>>> hns3 PMD cannot implement the above functions due to hardware limit= ation. > >>>>> we may need add a check that specified RSS queues cannot be support= ed > >>>>> when specified packets types. > >>>>> And only the packet type is specified, which meets the requirements= of > >>>>> rte_flow API. > >>>>> The check for the RTE_ETH_MQ_RX_RSS_FLAG flag in rte_flow is not co= rrect. > >>>>> Thanks, Ori and Stephen=F0=9F=98=81 > >>>>> > >>>>> But, I think, it is necessary for the '.rss_hash_update' and > >>>>> '.reta_update' APIs > >>>>> in eth_dev_ops to verify this flag. What do you think? @Thomas, > >>>>> @Ferruh, @Ori and @Stephen. > >>>> What's your take on it? I am looking forward to your reply. Thanks! > >>> I am not sure why you want to check this flag. > >> I want to make sure that the behavior that PMD configured RSS is > >> consistent across different interfaces. The RTE_ETH_MQ_RX_RSS_FLAG > >> flag is a switch to enable RSS hash. If the switch isn't open, some > >> PMD do not configure RSS function. I think the consistency is necessar= y. > >> If not set RSS muti-queue mode, it is unnecessary to configure RSS. > >> > >>> I can imagine we configure the hash and the table before enabling RSS > >>> with the RTE_ETH_MQ_RX_RSS_FLAG flag. > >> The flag is derived from dev_configure() which also configures > >> hash and key. I don't think it makes sense to configure hash and > >> reta before calling dev_configure. Because they'll be updated. > >> This is similar to configuring mtu. > > OK I see your point. > > So you would like to return an error in RSS functions > > if the flag RTE_ETH_MQ_RX_RSS_FLAG is not set? > Yes > > Should it be checked in ethdev library or PMDs? > I think it's better to put it in the ethdev layer if we do it. > Should we add this check in 'rss_hash_update' and 'reta_update' APIs? I'm OK with adding the check in ethdev.