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 104A9C433F5 for ; Tue, 22 Mar 2022 17:13:40 +0000 (UTC) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D9DA940E64; Tue, 22 Mar 2022 18:13:38 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 428CB40694 for ; Tue, 22 Mar 2022 18:13:37 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 795AE5C0197; Tue, 22 Mar 2022 13:13:36 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 22 Mar 2022 13:13:36 -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=jnj1dHWwjJkB9J p+YQJDrX61Rm3U/B7OTHKF9clsDP8=; b=tVdy9nCfAMbx4qCQgSAlkuDAmntGCb u/OEyzA8xc0Dju/P/NKo/sLUftSjwf/nSzOQxxGccMGH+89YFW6XNQR4vEOg4nhV 4PIr9dfo94u/Z5NpYav0pskKRVYuoSEL3Yb90qdrCeJ9tEaolLr6zc0ADMOiwx6d GzJKVSvVsNzb0eESjYqD0yvKbq4wnGzwjUj7LSz7UjGmRiJdOGcZyiDxl8CBCYfC rXxecMTqjqZxc1YiL7mZJRz3RjYMZ1nBocoMTZWsTw3F5Z3J6bm3PBm6qraDJquL xt2e3esvMf4WXiW3jxlKw5hvgKHGEHzdIHKuNpnQv2yCMk/jaLsfq5dQ== 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=jnj1dHWwjJkB9Jp+YQJDrX61Rm3U/B7OTHKF9clsD P8=; b=XqwfFwv4j9BFHO5zBrcIa69yXJqmnnAdYmyjyfLLDRoJ0y9q0Yml87UCd eUXqwLJEld4L8CMUpsu3THxX+F+f6ebq2y+fp1QiC5L+51T66KCZkKonnZMEHlDG NFIynsb7MS7I5jeSk59bjwCKZPnHJO0U9UbojSlcqM/ETPPXJ95svTgbLbVfC5TQ UGFHGKw2quu40koo0KYFgC5P/Fv42Koz93xkWp55YM9ckXE9bY6PmAtFb66V4A/f ziyNTud8zTiut1dmLuq2l5QZxzAiRpVkPxjWzxAKyBdt9/ShstHzJeDI0VYMNKqf WBiMWzmiMvMx0XjufqH7UkYomGc2w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudeghedgleehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepkeethedtieevhfeigeejleegudefjeehkeekteeuveeiuedvveeu tdejveehveetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 22 Mar 2022 13:13:33 -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: Tue, 22 Mar 2022 18:13:32 +0100 Message-ID: <8080441.NyiUUSuA9g@thomas> In-Reply-To: <03375cab-d228-50bf-7005-06fc718c63e9@huawei.com> References: <20220228032146.37407-1-humin29@huawei.com> <03375cab-d228-50bf-7005-06fc718c63e9@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 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=20 > >>>>>>>> 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=20 > >>>>>>>> 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 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=20 > >>>>>> 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 RSS > >>>>> 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 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=20 > >> HW/PMD limitation. > >> In your example non TCP traffic will be routed to one of the 4 queues= =20 > >> (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=20 > >> 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=20 > >> 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 limitatio= n. > > we may need add a check that specified RSS queues cannot be supported=20 > > when specified packets types. > > And only the packet type is specified, which meets the requirements of= =20 > > rte_flow API. > > The check for the RTE_ETH_MQ_RX_RSS_FLAG flag in rte_flow is not correc= t. > > Thanks, Ori and Stephen=F0=9F=98=81 > > > > But, I think, it is necessary for the '.rss_hash_update' and=20 > > '.reta_update' APIs > > in eth_dev_ops to verify this flag. What do you think? @Thomas,=20 > > @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 can imagine we configure the hash and the table before enabling RSS with the RTE_ETH_MQ_RX_RSS_FLAG flag.