From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 31163C622 for ; Tue, 28 Apr 2015 16:49:57 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 28 Apr 2015 07:46:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,664,1422950400"; d="scan'208";a="686896750" Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98]) by orsmga001.jf.intel.com with ESMTP; 28 Apr 2015 07:46:30 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by PGSMSX106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 28 Apr 2015 22:46:29 +0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.162]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.69]) with mapi id 14.03.0224.002; Tue, 28 Apr 2015 22:46:27 +0800 From: "Zhang, Helin" To: Gleb Natapov Thread-Topic: i40e and RSS woes Thread-Index: AQHQgZS2esAWqZ8OPkm7FI4SITip1J1igG/A Date: Tue, 28 Apr 2015 14:46:27 +0000 Message-ID: References: <20150216133654.GQ24740@cloudius-systems.com> <20150219145010.GB29513@cloudius-systems.com> <20150302125619.GE3806@cloudius-systems.com> <20150305063911.GA23629@cloudius-systems.com> <20150428092121.GE4879@cloudius-systems.com> In-Reply-To: <20150428092121.GE4879@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: Tue, 28 Apr 2015 14:49:59 -0000 Hi Gleb I don't think the fix is in the master branch. I will double check it and g= et back to you later. Thank you very much for the reminder! Regards, Helin > -----Original Message----- > From: Gleb Natapov [mailto:gleb@cloudius-systems.com] > Sent: Tuesday, April 28, 2015 5:21 PM > To: Zhang, Helin > Cc: dev@dpdk.org > Subject: Re: i40e and RSS woes >=20 > Hi, >=20 > I didn't follow DPDK development to close lately. Was those problem fixed > already? >=20 > On Thu, Mar 05, 2015 at 06:56:14AM +0000, Zhang, Helin wrote: > > > > > > > -----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 > > > > > > 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 > > > > 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. > > > > > > > Thanks, as I said below when I configure reta by myself everything > > > work as expected - traffic is received on all queues, so I am > > > curious if in some scenarios my code can break. > > > > > > > > > > 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 n= ot > 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. > > > > > > > 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 key 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. > > > > > > > > > > > > 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. > > > > > > > What you've said above is exactly the issue! My code does not work > > > if a key 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 application will not work (short of querying key b= ack > 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 implementati= on. > > Returning with an error might be the best way for all PMDs. I will unif= y it > later. > > > > Really good findings and suggestions from you! Thank you very much! > > >=20 > -- > Gleb.