[dpdk-dev] i40e and RSS woes

[Zhang, Helin]

> -----Original Message-----
> From: Gleb Natapov [mailto:gleb at cloudius-systems.com]
> Sent: Thursday, March 5, 2015 2:39 PM
> To: Zhang, Helin
> Cc: dev at 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 at cloudius-systems.com]
> > > Sent: Monday, March 2, 2015 8:56 PM
> > > To: dev at 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!

Regards,
Helin

> 
> --
> 			Gleb.