From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id E8802C506 for ; Tue, 28 Apr 2015 11:21:23 +0200 (CEST) Received: by wgyo15 with SMTP id o15so144081625wgy.2 for ; Tue, 28 Apr 2015 02:21:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to; bh=fAICKwQfluXVF1N2b3o+0vZzAzV+9HOw84IzODQgcE8=; b=Rqz4x/Ozn6V/IyNvzLgn14rE+B47lwKKgyT6gU1aipygxK+oPGs4jJECD4HfJ92aEB OPw5oBLAIn2pCg0Zw9BdN0T3vG9OxuqkoymsR1TPBYE2n8HbqjKdHx26qaCZ2tW1jH6k Tm+N0fs+VvqupSlrvJYUg1gRPXvDoj8NhD4BkQ995XvIqoTl2g4A4TCMywMA9U7/0dMY +QdRRNZwudBbnD5/oo2m5AV/61j9LgUpzRhaRLSPasZ+2NNgVv+5EOxR6PE7YTYpQia/ W3oAR5GH49FL8Aw/kKyRy1ShButf8Dt3XEyBEY9mCEq0MGEdh4anUvF8CneyyCv9m99v pOrg== X-Gm-Message-State: ALoCoQm261VOTmv+gBejvyfultvszgSDKw3W70EdxUN0Xbpvbk50MeAVYrzzM8W/i2Y7Nf557CuB X-Received: by 10.180.77.83 with SMTP id q19mr27550197wiw.89.1430212883692; Tue, 28 Apr 2015 02:21:23 -0700 (PDT) Received: from trex.cloudius-systems.com ([212.143.139.214]) by mx.google.com with ESMTPSA id cs4sm33226552wjb.31.2015.04.28.02.21.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Apr 2015 02:21:22 -0700 (PDT) Received: by trex.cloudius-systems.com (Postfix, from userid 1042) id 2C2EA83F79; Tue, 28 Apr 2015 12:21:21 +0300 (IDT) Date: Tue, 28 Apr 2015 12:21:21 +0300 From: Gleb Natapov To: "Zhang, Helin" Message-ID: <20150428092121.GE4879@cloudius-systems.com> References: <20150216133654.GQ24740@cloudius-systems.com> <20150219145010.GB29513@cloudius-systems.com> <20150302125619.GE3806@cloudius-systems.com> <20150305063911.GA23629@cloudius-systems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 09:21:24 -0000 Hi, I didn't follow DPDK development to close lately. Was those problem fixed already? 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 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. > > > > > 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 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! > -- Gleb.