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 E85AAA04FF; Wed, 23 Mar 2022 10:14:24 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 922B041140; Wed, 23 Mar 2022 10:14:24 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 16B8641104 for ; Wed, 23 Mar 2022 10:14:23 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 872BB5C013A; Wed, 23 Mar 2022 05:14:22 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 23 Mar 2022 05:14:22 -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=V6Myw3iE0HG/rP bRR3EsRAc7za5MAPz2LOFgM96/Cms=; b=LibIkXC3VAPXBkYXbebK9EOH0dhtTs NyovO92gBUB3Y3dJczvrbce7gaHnzDl+hMKTvT0PEsITxNtM2BShseNoO7rXrgqm ZfzCD0jnagXqH7dFADWpDwFXHAH79xeO1HB1NuLqiIqlie5+RPVLtvDU43IBAlLd EhlKzFA4u4ayOBoUv4gb5kwQDB76FoLy6pbCSWXKcTwlehn/AZH9NTeGF31oQMZ5 WiwiEK13kzzB2sP1K1My2t+PmXN5IqmATTiiQ885Kj2Yd1p3JFpJz2Gl5q7r7zOh uy3y2cczE6XR882cE/nKMTD35nDcskiU+cUoJ9nAySbaFZi2GwBR15Tg== 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=V6Myw3iE0HG/rPbRR3EsRAc7za5MAPz2LOFgM96/C ms=; b=Baauv37K8wJZpVouB7iI2NpGZQdQxqFBAEU7v+hP9SacDthp7GCBSJQdK Itfyn8EnpZr1XPf91/Lr1VmPCqFLzKz878iL4OGE9q+h4UTb8a41s2UBtr97nR3+ iyLvPJsG+H+w6LIRa+AiafjCtbO2iHYSLZFuY0sG3g1FD0R3hKeMBKhU+P2Xlj4E guNY/vlf4sF3zPwW/6oQWCXn3rfjZ/CN+3z1yDSHy8nj+HOryMXwR0mtlXbUTySB xJ1+XLsIFawgN8XcCc2fDFncZRXexgtn6LFisFrklS24GhhbgSfLKVQWkO4XkZf+ AeWaumMxy6fCEsZLG5d4LW4Svbzrg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudegjecutefuodetggdotefrodftvfcurf hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhmrghsucfo ohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtffrrg htthgvrhhnpeekteehtdeivefhieegjeelgedufeejheekkeetueevieeuvdevuedtjeev heevteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 23 Mar 2022 05:14:20 -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 10:14:18 +0100 Message-ID: <1785739.atdPhlSkOF@thomas> In-Reply-To: References: <20220228032146.37407-1-humin29@huawei.com> <8080441.NyiUUSuA9g@thomas> 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 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 can = 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 peo= ple. > >>>>>>>>> > >>>>>>>>> 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 not a > >>>>>>> global one. > >>>>>>> For example create RSS that sends TCP to some queues while othe R= SS > >>>>>>> will send > >>>>>>> UDP traffic to different queues. > >>>>>> I'm a little confused now. The "per rule" also seems to be a global > >>>>>> configuration. > >>>>>> Example: > >>>>>> - start PMD with 0,1,2,3 > >>>>>> - create TCP packets to 2,3 queues. At this moment, only 2,3 qu= eues > >>>>>> 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 l= ike > >>>>> 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 queues > >>>> (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 limitat= ion. > >>> we may need add a check that specified RSS queues cannot be supported > >>> 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 corr= ect. > >>> 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! > >=20 > > I am not sure why you want to check this flag. >=20 > 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 necessary. > If not set RSS muti-queue mode, it is unnecessary to configure RSS. >=20 > > I can imagine we configure the hash and the table before enabling RSS > > with the RTE_ETH_MQ_RX_RSS_FLAG flag. >=20 > 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? Should it be checked in ethdev library or PMDs?