Re: [dpdk-dev] i40e and RSS woes

["Zhang, Helin" <helin.zhang@intel.com>]

Hi Gleb

I don't think the fix is in the master branch. I will double check it and get 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
> 
> 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.