From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 094D35A76 for ; Thu, 5 Mar 2015 07:56:18 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 04 Mar 2015 22:56:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,345,1422950400"; d="scan'208";a="660728664" Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86]) by orsmga001.jf.intel.com with ESMTP; 04 Mar 2015 22:56:16 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 5 Mar 2015 14:56:15 +0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.161]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.46]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 14:56:14 +0800 From: "Zhang, Helin" To: Gleb Natapov Thread-Topic: i40e and RSS woes Thread-Index: AQHQTFNhTNj2ABdvbUa5rfwW5b77850IscqAgATEGwD//4mFgIAAiYjA Date: Thu, 5 Mar 2015 06:56:14 +0000 Message-ID: References: <20150216133654.GQ24740@cloudius-systems.com> <20150219145010.GB29513@cloudius-systems.com> <20150302125619.GE3806@cloudius-systems.com> <20150305063911.GA23629@cloudius-systems.com> In-Reply-To: <20150305063911.GA23629@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: Thu, 05 Mar 2015 06:56:19 -0000 > -----Original Message----- > From: Gleb Natapov [mailto:gleb@cloudius-systems.com] > Sent: Thursday, March 5, 2015 2:39 PM > To: Zhang, Helin > Cc: dev@dpdk.org > Subject: Re: i40e and RSS woes >=20 > On Thu, Mar 05, 2015 at 05:56:27AM +0000, 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 RS= S 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. > > > Thanks, as I said below when I configure reta by myself everything work a= s > expected - traffic is received on all queues, so I am curious if in some = scenarios > my code can break. >=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 t= raffic. > > > > > > > > > > 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. > > > I saw rss_key_len of course, my question is how my code suppose to know > what value to set it to? Why required key length is not part of a device > capability query (or is it and I missed it)? The only way I found to get = key length > is to quire device for a key, and check rss_key_len. If it is zero then k= ey is 40 > bytes, otherwise whatever rss_key_len says. This method is more of a hack > then proper way to do it. I think it was missed. I will add it soon later. >=20 > > > > > 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. > > > What you've said above is exactly the issue! My code does not work if a k= ey > used by HW is not the same as was set by application, but since I get no = error > when my setting is ignored the is not way for me to know that my applicat= ion > will not work (short of querying key back and comparing which is again a = hack). > Device configuration should fail if it cannot apply my settings. After I checked the code, different PMD may have different implementation. Returning with an error might be the best way for all PMDs. I will unify it= later. Really good findings and suggestions from you! Thank you very much! Regards, Helin >=20 > -- > Gleb.