[dpdk-dev] i40e and RSS woes

[dpdk-dev] i40e and RSS woes

[Gleb Natapov]

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 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?
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.

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.

Re: [dpdk-dev] i40e and RSS woes

[Gleb Natapov]

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 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?
> 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.
> 
> 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.

Re: [dpdk-dev] i40e and RSS woes

[Gleb Natapov]

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 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?
> > 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.
> > 
> > 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.

Re: [dpdk-dev] i40e and RSS woes

[Zhang, Helin]

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.

> > > 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.

Re: [dpdk-dev] i40e and RSS woes

[Gleb Natapov]

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.

Re: [dpdk-dev] i40e and RSS woes

[Zhang, Helin]

> -----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!

Regards,
Helin

> 
> --
> 			Gleb.

Re: [dpdk-dev] i40e and RSS woes

[Gleb Natapov]

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.

Re: [dpdk-dev] i40e and RSS woes

[Zhang, Helin]

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.

Re: [dpdk-dev] i40e and RSS woes

[Vlad Zolotarov]

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.

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.

Re: [dpdk-dev] i40e and RSS woes

[Vlad Zolotarov]

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.
>

Re: [dpdk-dev] i40e and RSS woes

[Zhang, Helin]

> -----Original Message-----
> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com]
> Sent: Monday, August 24, 2015 4:14 AM
> To: Zhang, Helin; Gleb Natapov; dev@dpdk.org
> Subject: Re: [dpdk-dev] i40e and RSS woes
> 
> 
> 
> 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.
Could you help to refer to the data sheet of 'Hash Filter', 'Receive Queue Regions', it
is said that '1, 2, 4, 8, 16, 32, 64' are the supported queue regions.
Yes, we should support more than 64 queues per port, but for rss, it should be one
of '1, 2, 4, 8, 16, 32, 64'.

Thanks,
Helin

> 
> Pls., comment.
> 
> 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.

Re: [dpdk-dev] i40e and RSS woes

[Vlad Zolotarov]

On 08/24/15 20:51, Zhang, Helin wrote:
>
>> -----Original Message-----
>> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com]
>> Sent: Monday, August 24, 2015 4:14 AM
>> To: Zhang, Helin; Gleb Natapov; dev@dpdk.org
>> Subject: Re: [dpdk-dev] i40e and RSS woes
>>
>>
>>
>> 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.
> Could you help to refer to the data sheet of 'Hash Filter', 'Receive Queue Regions', it
> is said that '1, 2, 4, 8, 16, 32, 64' are the supported queue regions.
> Yes, we should support more than 64 queues per port, but for rss, it should be one
> of '1, 2, 4, 8, 16, 32, 64'.

"The VSIs support 8 regions of receive queues that are aimed mainly for
the TCs. The TC regions are defined per VSI by the VSIQF_TCREGION
register. The region sizes (defined by the TC_SIZE fields) can be any of
the following value: 1, 2, 4, 8, 16, 32, 64 as long as the total number of
queues do not exceed the VSI allocation. These regions starts at the
offset defined by the TC_OFFSET parameter. According to the region
size, the ‘n’ LS bits of the Queue Index from the LUT are enabled."

I think the above says that the region sizes may only be one of the 
mentioned values.

AFAIU this doesn't mean that the number or RSS queues has to be the same 
- it may not exceed it.

Just like it's stated in the "Outcome Queue Index" definition the final 
mapping to the PF index space is done using the
VSILAN_QTABLE or VSILAN_QBASE registers (a.k.a. RSS indirection table).

For instance if u have a region of size 8 u may configure 3 RSS queues 
by setting the following RSS table:
0,1,2,0,1,2,0,1

>
> Thanks,
> Helin
>
>> Pls., comment.
>>
>> 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.

Re: [dpdk-dev] i40e and RSS woes

[Zhang, Helin]

> -----Original Message-----
> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com]
> Sent: Monday, August 24, 2015 11:26 AM
> To: Zhang, Helin; Gleb Natapov
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] i40e and RSS woes
> 
> 
> 
> On 08/24/15 20:51, Zhang, Helin wrote:
> >
> >> -----Original Message-----
> >> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com]
> >> Sent: Monday, August 24, 2015 4:14 AM
> >> To: Zhang, Helin; Gleb Natapov; dev@dpdk.org
> >> Subject: Re: [dpdk-dev] i40e and RSS woes
> >>
> >>
> >>
> >> 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.
> > Could you help to refer to the data sheet of 'Hash Filter', 'Receive
> > Queue Regions', it is said that '1, 2, 4, 8, 16, 32, 64' are the supported queue
> regions.
> > Yes, we should support more than 64 queues per port, but for rss, it
> > should be one of '1, 2, 4, 8, 16, 32, 64'.
> 
> "The VSIs support 8 regions of receive queues that are aimed mainly for the TCs.
> The TC regions are defined per VSI by the VSIQF_TCREGION register. The region
> sizes (defined by the TC_SIZE fields) can be any of the following value: 1, 2, 4, 8,
> 16, 32, 64 as long as the total number of queues do not exceed the VSI allocation.
> These regions starts at the offset defined by the TC_OFFSET parameter.
> According to the region size, the 'n' LS bits of the Queue Index from the LUT are
> enabled."
> 
> I think the above says that the region sizes may only be one of the mentioned
> values.
> 
> AFAIU this doesn't mean that the number or RSS queues has to be the same
> - it may not exceed it.
> 
> Just like it's stated in the "Outcome Queue Index" definition the final mapping to
> the PF index space is done using the VSILAN_QTABLE or VSILAN_QBASE registers
> (a.k.a. RSS indirection table).
> 
> For instance if u have a region of size 8 u may configure 3 RSS queues by setting
> the following RSS table:
> 0,1,2,0,1,2,0,1
I tend to agree with you. Anyway, I am working on supporting more queues per port than 64,
and I will take this into account. If not other strong reasons, I will change it. Thank you very much!

Regards,
Helin

> 
> >
> > Thanks,
> > Helin
> >
> >> Pls., comment.
> >>
> >> 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.

Re: [dpdk-dev] i40e and RSS woes

[Vladislav Zolotarov]

On Aug 24, 2015 21:54, "Zhang, Helin" <helin.zhang@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com]
> > Sent: Monday, August 24, 2015 11:26 AM
> > To: Zhang, Helin; Gleb Natapov
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] i40e and RSS woes
> >
> >
> >
> > On 08/24/15 20:51, Zhang, Helin wrote:
> > >
> > >> -----Original Message-----
> > >> From: Vlad Zolotarov [mailto:vladz@cloudius-systems.com]
> > >> Sent: Monday, August 24, 2015 4:14 AM
> > >> To: Zhang, Helin; Gleb Natapov; dev@dpdk.org
> > >> Subject: Re: [dpdk-dev] i40e and RSS woes
> > >>
> > >>
> > >>
> > >> 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.
> > > Could you help to refer to the data sheet of 'Hash Filter', 'Receive
> > > Queue Regions', it is said that '1, 2, 4, 8, 16, 32, 64' are the
supported queue
> > regions.
> > > Yes, we should support more than 64 queues per port, but for rss, it
> > > should be one of '1, 2, 4, 8, 16, 32, 64'.
> >
> > "The VSIs support 8 regions of receive queues that are aimed mainly for
the TCs.
> > The TC regions are defined per VSI by the VSIQF_TCREGION register. The
region
> > sizes (defined by the TC_SIZE fields) can be any of the following
value: 1, 2, 4, 8,
> > 16, 32, 64 as long as the total number of queues do not exceed the VSI
allocation.
> > These regions starts at the offset defined by the TC_OFFSET parameter.
> > According to the region size, the 'n' LS bits of the Queue Index from
the LUT are
> > enabled."
> >
> > I think the above says that the region sizes may only be one of the
mentioned
> > values.
> >
> > AFAIU this doesn't mean that the number or RSS queues has to be the same
> > - it may not exceed it.
> >
> > Just like it's stated in the "Outcome Queue Index" definition the final
mapping to
> > the PF index space is done using the VSILAN_QTABLE or VSILAN_QBASE
registers
> > (a.k.a. RSS indirection table).
> >
> > For instance if u have a region of size 8 u may configure 3 RSS queues
by setting
> > the following RSS table:
> > 0,1,2,0,1,2,0,1
> I tend to agree with you. Anyway, I am working on supporting more queues
per port than 64,
> and I will take this into account. If not other strong reasons, I will
change it. Thank you very much!

Great! Thanks a lot, Helin.

>
> Regards,
> Helin
>
> >
> > >
> > > Thanks,
> > > Helin
> > >
> > >> Pls., comment.
> > >>
> > >> 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.
>