From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by dpdk.org (Postfix) with ESMTP id 689CE7EEF for ; Mon, 24 Aug 2015 13:40:18 +0200 (CEST) Received: by wicne3 with SMTP id ne3so69427007wic.0 for ; Mon, 24 Aug 2015 04:40:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=5jH0ZZIjxFlg3bJOibVaRVfwMza+GcaW9jFUQtr7zHk=; b=PlcfUNOO5o6QArN0EBNPOZxSfFNAPHhWgoiLSPdTjjN8liiG2e/MUs5MYe8d9n/4Pg qhZJXNY72cC7XoQM0RSJljE8ORJ05DU1RGK5FloVDj+S1I/KbEHHmxLOUPu0+5HVT6uw fs7ML6629Hs6BVkEnrUkH61ynwM6EODfd8Bna6vyhZYcWNlkt1SitCaIUzxnU9nsymD4 PCDofoqBWbVm5/6c89XQ8Or/ZykCxxcxTLKR2vvkuDTjKuJTDL8olbSfrbUw7KxSvPAW S8N+ol2NqRqlvm9cuOo6975CdiekTJS9qHQ34yylQW2UuYhf4WBxuZT3s+qT/4RqYVZ7 TdjA== X-Gm-Message-State: ALoCoQn5h18kbTVVajLpTVloARDl09DFaiKx09FKOiixgI2gTOCbpcLDwYr1oP/h9k2XQ4yNah7o X-Received: by 10.194.81.67 with SMTP id y3mr38290958wjx.7.1440416418161; Mon, 24 Aug 2015 04:40:18 -0700 (PDT) Received: from [10.0.0.166] ([37.142.229.250]) by smtp.googlemail.com with ESMTPSA id v8sm22793774wjr.15.2015.08.24.04.40.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Aug 2015 04:40:17 -0700 (PDT) To: "Zhang, Helin" , Gleb Natapov , "dev@dpdk.org" References: <20150216133654.GQ24740@cloudius-systems.com> <20150219145010.GB29513@cloudius-systems.com> <20150302125619.GE3806@cloudius-systems.com> <55DAFC65.7000106@cloudius-systems.com> From: Vlad Zolotarov Message-ID: <55DB02A0.50604@cloudius-systems.com> Date: Mon, 24 Aug 2015 14:40:16 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55DAFC65.7000106@cloudius-systems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 11:40:18 -0000 On 08/24/15 14:13, Vlad Zolotarov wrote: > > > On 03/05/15 07:56, 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. > > 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. > > Could u, pls., clarify what is that "i40e queue configuration" that > requires this alignment u are referring above? > > 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. > > Therefore, from the first look it seems that this rounding may be > safely removed unless I've missed something. > > Pls., comment. Have just noticed this: /* Each of below queue pairs should be power of 2 since it's the precondition after TC configuration applied */ uint16_t lan_nb_qps; /* The number of queue pairs of LAN */ I still couldn't find any justification for either requiring the above or requiring any correlation between the number of Tx queues (whatever it is) and the number of Rx queues in the HW spec. It seems that spec implies that Rx and Tx configuration is completely orthogonal (as it should be). Could u, pls., clarify how TC configuration imposes a requirement on a number of Rx queues to be a power of 2? thanks in advance, vlad > > thanks, > vlad > >> >>>>> 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 >> 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. >> >> 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. >