From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 3842E5A35 for ; Mon, 24 Aug 2015 19:51:51 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 24 Aug 2015 10:51:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,739,1432623600"; d="scan'208";a="790028218" Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105]) by orsmga002.jf.intel.com with ESMTP; 24 Aug 2015 10:51:49 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 25 Aug 2015 01:51:47 +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 01:51:46 +0800 From: "Zhang, Helin" To: Vlad Zolotarov , Gleb Natapov Thread-Topic: [dpdk-dev] i40e and RSS woes Thread-Index: AQHQ3l3ykP8moEY5+kanW1VF+Jh5BZ4bbRRg Date: Mon, 24 Aug 2015 17:51:45 +0000 Message-ID: References: <20150216133654.GQ24740@cloudius-systems.com> <20150219145010.GB29513@cloudius-systems.com> <20150302125619.GE3806@cloudius-systems.com> <55DAFC65.7000106@cloudius-systems.com> In-Reply-To: <55DAFC65.7000106@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 17:51:51 -0000 > -----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 >=20 >=20 >=20 > On 03/05/15 07:56, Zhang, Helin wrote: > > Hi Gleb > > > > Sorry for late! I am struggling on my tasks for the following DPDK rele= ase 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 i= ssues. > >>>> > >>>> 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. >=20 > 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. >=20 > Could u, pls., clarify what is that "i40e queue configuration" that requi= res this > alignment u are referring above? >=20 > 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 not an option. >=20 > 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 supported 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'. Thanks, Helin >=20 > Pls., comment. >=20 > thanks, > vlad >=20 > > > >>>> 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 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 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 defa= ult 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.