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 1B19BA0503; Mon, 21 Mar 2022 08:14:36 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9F6604114D; Mon, 21 Mar 2022 08:14:35 +0100 (CET) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id CAB104113D for ; Mon, 21 Mar 2022 08:14:33 +0100 (CET) Received: from kwepemi100024.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KMQn65tmYzfZ2q; Mon, 21 Mar 2022 15:12:58 +0800 (CST) Received: from kwepemm600004.china.huawei.com (7.193.23.242) by kwepemi100024.china.huawei.com (7.221.188.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 21 Mar 2022 15:14:30 +0800 Received: from [10.67.103.231] (10.67.103.231) by kwepemm600004.china.huawei.com (7.193.23.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 21 Mar 2022 15:14:30 +0800 Message-ID: <03375cab-d228-50bf-7005-06fc718c63e9@huawei.com> Date: Mon, 21 Mar 2022 15:14:23 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH 2/6] net/hns3: fix inconsistent enabled RSS behavior From: "lihuisong (C)" To: Ori Kam , Ferruh Yigit , "Min Hu (Connor)" , "dev@dpdk.org" , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , "Andrew Rybchenko" , Qi Zhang CC: Olivier Matz , Ajit Khaparde , "jerinj@marvell.com" , Stephen Hemminger , Slava Ovsiienko , huangdaode References: <20220228032146.37407-1-humin29@huawei.com> <20220228032146.37407-3-humin29@huawei.com> <5b829b45-220b-daa2-19e4-3b3fc746d152@huawei.com> <7a17f2d7-758c-9dde-5550-b52622d17ef5@huawei.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.103.231] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemm600004.china.huawei.com (7.193.23.242) X-CFilter-Loop: Reflected 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, 在 2022/3/10 16:08, lihuisong (C) 写道: > > 在 2022/3/9 17:55, Ori Kam 写道: >> Hi Lihusiong, >> >>> -----Original Message----- >>> From: lihuisong (C) >>> Sent: Wednesday, March 9, 2022 10:03 AM >>> Subject: Re: [PATCH 2/6] net/hns3: fix inconsistent enabled RSS >>> behavior >>> >>> >>> 在 2022/3/3 10:47, lihuisong (C) 写道: >>>> Hi, Ori, >>>> >>>> 在 2022/3/2 22:07, Ori Kam 写道: >>>>> Hi Lihuisong, >>>>> >>>>>> -----Original Message----- >>>>>> From: lihuisong (C) >>>>>> Sent: Wednesday, March 2, 2022 4:10 AM >>>>>> Subject: Re: [PATCH 2/6] net/hns3: fix inconsistent enabled RSS >>>>>> behavior >>>>>> >>>>>> >>>>>> 在 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 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, >>>>>> 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 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 >> 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 limitation. > 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 correct. > Thanks, Ori and Stephen😁 > > 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! >> >>>>>> 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_flow >>>>>> API. >>>>>> >>>>>> For example, hinic, axbge, bnxt, cnxk, otx2, and ena. >>>>>> >>>>>>> . >>>>>   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 >>>>> 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 >>>>> only rules created by >>>>> rte_flow will have the RSS, for matching traffc. >>>>> >>>>> Best, >>>>> Ori > .