From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id C333B5A83 for ; Mon, 24 Aug 2015 20:54:52 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP; 24 Aug 2015 11:54:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,740,1432623600"; d="scan'208";a="790063184" Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86]) by orsmga002.jf.intel.com with ESMTP; 24 Aug 2015 11:54:50 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 25 Aug 2015 02:54:48 +0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.210]) by shsmsx102.ccr.corp.intel.com ([169.254.2.206]) with mapi id 14.03.0224.002; Tue, 25 Aug 2015 02:54:47 +0800 From: "Zhang, Helin" To: Vlad Zolotarov , Gleb Natapov Thread-Topic: [dpdk-dev] i40e and RSS woes Thread-Index: AQHQ3l3ykP8moEY5+kanW1VF+Jh5BZ4bbRRg//+EzoCAAIwj4A== Date: Mon, 24 Aug 2015 18:54:46 +0000 Message-ID: References: <20150216133654.GQ24740@cloudius-systems.com> <20150219145010.GB29513@cloudius-systems.com> <20150302125619.GE3806@cloudius-systems.com> <55DAFC65.7000106@cloudius-systems.com> <55DB61C9.7060709@cloudius-systems.com> In-Reply-To: <55DB61C9.7060709@cloudius-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] i40e and RSS woes X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 18:54:54 -0000 > -----Original Message----- > From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com] > Sent: Monday, August 24, 2015 11:26 AM > To: Zhang, Helin; Gleb Natapov > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] i40e and RSS woes >=20 >=20 >=20 > 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 > >>> release 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 > >>>>>> reta table, round down number of queues to power of two. Why is > >>>>>> this? If > >>> 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 > >> issue (rounding it down to the nearest power of 2) still hasn't been > >> addressed in the master branch. > >> > >> Could u, pls., clarify what is that "i40e queue configuration" that > >> requires 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 > >> queues would use the dev_data->nb_rx_queues (e.g. i40e_dev_rx_init()) > >> and wouldn't be able to know that i40e_pf_config_rss() something > >> different except for scanning the RSS table in HW which is of course n= ot an > option. > >> > >> Therefore, from the first look it seems that this rounding may be > >> safely removed unless I've missed something. > > Could you help to refer to the data sheet of 'Hash Filter', 'Receive > > Queue Regions', it is said that '1, 2, 4, 8, 16, 32, 64' are the suppor= ted queue > regions. > > Yes, we should support more than 64 queues per port, but for rss, it > > should be one of '1, 2, 4, 8, 16, 32, 64'. >=20 > "The VSIs support 8 regions of receive queues that are aimed mainly for t= he TCs. > The TC regions are defined per VSI by the VSIQF_TCREGION register. The re= gion > 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 of queues do not exceed the VSI al= location. > These regions starts at the offset defined by the TC_OFFSET parameter. > According to the region size, the 'n' LS bits of the Queue Index from the= LUT are > enabled." >=20 > I think the above says that the region sizes may only be one of the menti= oned > values. >=20 > AFAIU this doesn't mean that the number or RSS queues has to be the same > - it may not exceed it. >=20 > Just like it's stated in the "Outcome Queue Index" definition the final m= apping to > the PF index space is done using the VSILAN_QTABLE or VSILAN_QBASE regist= ers > (a.k.a. RSS indirection table). >=20 > For instance if u have a region of size 8 u may configure 3 RSS queues by= setting > the following RSS table: > 0,1,2,0,1,2,0,1 I tend to agree with you. Anyway, I am working on supporting more queues pe= r port than 64, and I will take this into account. If not other strong reasons, I will chan= ge it. Thank you very much! Regards, Helin >=20 > > > > Thanks, > > Helin > > > >> Pls., comment. > >> > >> thanks, > >> vlad > >> > >>>>>> I configure reta by my own using all of the queues everything > >>>>>> seams to be working. To add insult to injury I do not get any > >>>>>> errors during configuration some queues just do not receive any tr= affic. > >>>>>> > >>>>>> 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 > >>> to rework it > >> with clear descriptions. > >>>>>> And again, device configuration does not fail when wrong key > >>>>>> length 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 > >>> default 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.