From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vlad Zolotarov Subject: Re: i40e and RSS woes Date: Mon, 24 Aug 2015 21:26:17 +0300 Message-ID: <55DB61C9.7060709@cloudius-systems.com> References: <20150216133654.GQ24740@cloudius-systems.com> <20150219145010.GB29513@cloudius-systems.com> <20150302125619.GE3806@cloudius-systems.com> <55DAFC65.7000106@cloudius-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: "Zhang, Helin" , Gleb Natapov Return-path: Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by dpdk.org (Postfix) with ESMTP id 767EA5A6F for ; Mon, 24 Aug 2015 20:26:20 +0200 (CEST) Received: by widdq5 with SMTP id dq5so58367377wid.1 for ; Mon, 24 Aug 2015 11:26:20 -0700 (PDT) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 08/24/15 20:51, Zhang, Helin wrote: > >> -----Original Message----- >> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com] >> Sent: Monday, August 24, 2015 4:14 AM >> To: Zhang, Helin; Gleb Natapov; dev@dpdk.org >> Subject: Re: [dpdk-dev] i40e and RSS woes >> >> >> >> On 03/05/15 07:56, Zhang, Helin wrote: >>> Hi Gleb >>> >>> Sorry for late! I am struggling on my tasks for the following DPDK re= lease these >> days. >>>> -----Original Message----- >>>> From: Gleb Natapov [mailto:gleb@cloudius-systems.com] >>>> Sent: Monday, March 2, 2015 8:56 PM >>>> To: dev@dpdk.org >>>> Cc: Zhang, Helin >>>> Subject: Re: i40e and RSS woes >>>> >>>> Ping. >>>> >>>> On Thu, Feb 19, 2015 at 04:50:10PM +0200, Gleb Natapov wrote: >>>>> CCing i40e driver author in a hope to get an answer. >>>>> >>>>> On Mon, Feb 16, 2015 at 03:36:54PM +0200, Gleb Natapov wrote: >>>>>> I have an application that works reasonably well with ixgbe driver= , >>>>>> but when I try to use it with i40e I encounter various RSS related= issues. >>>>>> >>>>>> First one is that for some reason i40e, when it builds default ret= a >>>>>> table, round down number of queues to power of two. Why is this? I= f >>> It seems because of i40e queue configuration. We will check it more >>> and see if it can be changed or improved later. >> Helin, hi! >> Sorry for bringing it back but it seems that the RSS queues number iss= ue >> (rounding it down to the nearest power of 2) still hasn't been address= ed in the >> master branch. >> >> Could u, pls., clarify what is that "i40e queue configuration" that re= quires this >> alignment u are referring above? >> >> From what i could see "num" parameter is not propagated outside the >> i40e_pf_config_rss() in any form except for RSS table contents. >> This means that any code that would need to know the number of Rx queu= es >> would use the dev_data->nb_rx_queues (e.g. i40e_dev_rx_init()) and wou= ldn't >> be able to know that i40e_pf_config_rss() something different except f= or >> scanning the RSS table in HW which is of course not an option. >> >> Therefore, from the first look it seems that this rounding may be safe= ly removed >> unless I've missed something. > Could you help to refer to the data sheet of 'Hash Filter', 'Receive Qu= eue Regions', it > is said that '1, 2, 4, 8, 16, 32, 64' are the supported queue regions. > Yes, we should support more than 64 queues per port, but for rss, it sh= ould be one > of '1, 2, 4, 8, 16, 32, 64'. "The VSIs support 8 regions of receive queues that are aimed mainly for the TCs. The TC regions are defined per VSI by the VSIQF_TCREGION register. The region sizes (defined by the TC_SIZE fields) can be any of the following value: 1, 2, 4, 8, 16, 32, 64 as long as the total number o= f queues do not exceed the VSI allocation. These regions starts at the offset defined by the TC_OFFSET parameter. According to the region size, the =91n=92 LS bits of the Queue Index from the LUT are enabled." I think the above says that the region sizes may only be one of the=20 mentioned values. AFAIU this doesn't mean that the number or RSS queues has to be the same=20 - it may not exceed it. Just like it's stated in the "Outcome Queue Index" definition the final=20 mapping to the PF index space is done using the VSILAN_QTABLE or VSILAN_QBASE registers (a.k.a. RSS indirection table). For instance if u have a region of size 8 u may configure 3 RSS queues=20 by setting the following RSS table: 0,1,2,0,1,2,0,1 > > Thanks, > Helin > >> Pls., comment. >> >> thanks, >> vlad >> >>>>>> I configure reta by my own using all of the queues everything seam= s >>>>>> to be working. To add insult to injury I do not get any errors >>>>>> during configuration some queues just do not receive any traffic. >>>>>> >>>>>> The second problem is that for some reason i40e does not use 40 >>>>>> byte toeplitz hash key like any other driver, but it expects the >>>>>> key to be 52 bytes. And it would have being fine (if we ignore the >>>>>> fact that it contradicts MS spec), but how my high level code >>>>>> suppose to know >>>> that? >>> Actually a rss_key_len was introduced in struct rte_eth_rss_conf >>> recently. So the length should be indicated clearly. But I found the >>> annotations of that structure should have been reworked. I will try t= o rework it >> with clear descriptions. >>>>>> And again, device configuration does not fail when wrong key lengt= h >>>>>> is provided, it just uses some other key. Guys this kind of error >>>>>> handling is completely unacceptable. >>> If less length of key is provided, it will not be used at all, the de= fault key will be >> used. >>> So there is no issue as you said. But we need to add more clear >>> description for the structure of rte_eth_rss_conf. >>> >>> Thank you very much for the good comments! >>> >>> Regards, >>> Helin >>> >>>>>> The last one is more of a question. Why interface to change RSS >>>>>> hash function (XOR or toeplitz) is part of a filter configuration >>>>>> and not rss config? >>>>>> >>>>>> -- >>>>>> Gleb. >>>>> -- >>>>> Gleb. >>>> -- >>>> Gleb.