From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by dpdk.org (Postfix) with ESMTP id C52B45A7A for ; Thu, 5 Mar 2015 07:39:14 +0100 (CET) Received: by wesq59 with SMTP id q59so50937086wes.1 for ; Wed, 04 Mar 2015 22:39:14 -0800 (PST) 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=wG3kFx7FHb1hMhBWaQdrtviAdU+j01Y2saNXOzR9Z6k=; b=BdeUlGy4vdW0ZQk3puUntfru48Tzuzkw7yN+LR6katb+V9Ny7HdVKLy77LiKJhZyg2 yNUUhHOI+4mkfeMSukmPjRZeIIcENJO5mmig09SvHFblanzefy0qW60HoNGtGUPxXY/w UGJVEEyDEZK5yCaUoplDqXxNwrJNucuWcOfgJOda9PE85HBr+nJkufQ9btIXHHBJFUNN WDXqIt1j+CxYq623TvTIzxHmkaES/NpACoB9h5kN9edoVZ0Z6/uwPGzltrt9OQ8VyM/v j9+t0uMbBlgcePs58B0t2Ma/El42ZpGIvmVtE+aA5/2orVD7yMIW+TvF6gvYYLmuJFyL 2zuA== X-Gm-Message-State: ALoCoQnra6WO4B644HcKIrrj5SCuy0eYtrKQ42f8rjo+5qdcTkOcfDg6F+7Nj+b9VLRln3jlViEk X-Received: by 10.180.84.133 with SMTP id z5mr19438266wiy.25.1425537554616; Wed, 04 Mar 2015 22:39:14 -0800 (PST) Received: from trex.cloudius-systems.com (bzq-84-111-155-225.cablep.bezeqint.net. [84.111.155.225]) by mx.google.com with ESMTPSA id fm10sm10186515wib.7.2015.03.04.22.39.13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 22:39:13 -0800 (PST) Received: by trex.cloudius-systems.com (Postfix, from userid 1042) id 840F083EC1; Thu, 5 Mar 2015 08:39:11 +0200 (IST) Date: Thu, 5 Mar 2015 08:39:11 +0200 From: Gleb Natapov To: "Zhang, Helin" Message-ID: <20150305063911.GA23629@cloudius-systems.com> References: <20150216133654.GQ24740@cloudius-systems.com> <20150219145010.GB29513@cloudius-systems.com> <20150302125619.GE3806@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: Thu, 05 Mar 2015 06:39:15 -0000 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. > > > > 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. -- Gleb.