* [dpdk-dev] Questions about rte_flow_create APIs
@ 2020-07-03 6:44 oulijun
2020-07-05 11:58 ` Ori Kam
0 siblings, 1 reply; 3+ messages in thread
From: oulijun @ 2020-07-03 6:44 UTC (permalink / raw)
To: orika, ferruh.yigit; +Cc: dev, users
Hi, Guys
I am analyzing rte_flow_create API and test and is testing server parametric scenario.
When use testpmd and the following flow creat cmd:
testpmd> flow create 0 ingress pattern end actions rss func simple_xor / end
why the contents of rte_flow_action_rss is not same acquisition method after run the flowing codes.
struct rte_flow_action_rss conf;
rss_conf = action->conf;
the Value of unspecified parameter is not same acquisition method.
The rss_conf.type is default;
The rss_conf.key_len is deault;
The rss_conf.queue_num is deault;
However, the rss_conf.key is random and unpredictable
The result is that when the user does not specify the rss key, the driver will fill a random value into the hardware。
The rss key value found by the user is different from the first value, which results in the user not being able to use it correctly.
I think the reasonable behavior is that either the rss rule was not successfully created or the content of the rss key that was queried has not changed
testpmd> show port 0 rss-hash key
RSS functions:
all ipv4-frag ipv4-other ipv6-frag ipv6-other ip
RSS key:
4439796BB54C5023B675EA5B124F9F30B8A2C03DDFDC4D02A08C9B334AF64A4C05C6FA343958D8557D99583AE138C92E81150366
testpmd> flow create 0 ingress pattern eth / ipv4 / udp / end actions rss types ipv4-udp end queues end / end
Flow rule #0 created
testpmd> show port 0 rss-hash key
RSS functions:
all ipv4-udp udp
RSS key:
74657374706D6427732064656661756C74205253532068617368206B65792C206F7665727269646520697420666F722062657474
What do you think?
Thanks
Lijun Ou
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dpdk-dev] Questions about rte_flow_create APIs
2020-07-03 6:44 [dpdk-dev] Questions about rte_flow_create APIs oulijun
@ 2020-07-05 11:58 ` Ori Kam
2020-07-06 10:59 ` [dpdk-dev] 答复: " oulijun
0 siblings, 1 reply; 3+ messages in thread
From: Ori Kam @ 2020-07-05 11:58 UTC (permalink / raw)
To: oulijun, ferruh.yigit; +Cc: dev, users
Hi Oulijun,
First small comment, I think you sent the mail in HTML format,
please next time send it as plain text.
From: oulijun <oulijun@huawei.com>
Sent: Friday, July 3, 2020 9:45 AM
To: Ori Kam <orika@mellanox.com>; ferruh.yigit@intel.com
Cc: dev@dpdk.org; users@dpdk.org
Subject: Questions about rte_flow_create APIs
Hi, Guys
I am analyzing rte_flow_create API and test and is testing server parametric scenario.
When use testpmd and the following flow creat cmd:
testpmd> flow create 0 ingress pattern end actions rss func simple_xor / end
why the contents of rte_flow_action_rss is not same acquisition method after run the flowing codes.
struct rte_flow_action_rss conf;
rss_conf = action->conf;
the Value of unspecified parameter is not same acquisition method.
The rss_conf.type is default;
The rss_conf.key_len is deault;
The rss_conf.queue_num is deault;
However, the rss_conf.key is random and unpredictable
The result is that when the user does not specify the rss key, the driver will fill a random value into the hardware。
The rss key value found by the user is different from the first value, which results in the user not being able to use it correctly.
I think the reasonable behavior is that either the rss rule was not successfully created or the content of the rss key that was queried has not changed
testpmd> show port 0 rss-hash key
RSS functions:
all ipv4-frag ipv4-other ipv6-frag ipv6-other ip
RSS key:
4439796BB54C5023B675EA5B124F9F30B8A2C03DDFDC4D02A08C9B334AF64A4C05C6FA343958D8557D99583AE138C92E81150366
testpmd> flow create 0 ingress pattern eth / ipv4 / udp / end actions rss types ipv4-udp end queues end / end
Flow rule #0 created
testpmd> show port 0 rss-hash key
RSS functions:
all ipv4-udp udp
RSS key:
74657374706D6427732064656661756C74205253532068617368206B65792C206F7665727269646520697420666F722062657474
What do you think?
[Ori] I think this is a testpmd only issue, since it uses the same structure when it pass it to the pmd.
you can look at it in also in a different way.
1. the application create first flow using empty rss action, this mean that the flow gets the default RSS functions,
2. the application insert the flow you gave with different RSS function than the original one.
3. the application create a new flow with empty RSS, no the flow is created using the new RSS function and not the old one.
So I don’t think this is a true issue.
Best,
Ori
Thanks
Lijun Ou
^ permalink raw reply [flat|nested] 3+ messages in thread
* [dpdk-dev] 答复: Questions about rte_flow_create APIs
2020-07-05 11:58 ` Ori Kam
@ 2020-07-06 10:59 ` oulijun
0 siblings, 0 replies; 3+ messages in thread
From: oulijun @ 2020-07-06 10:59 UTC (permalink / raw)
To: Ori Kam, ferruh.yigit; +Cc: dev, users
Ok, thanks. I have adjusted.
发件人: Ori Kam [mailto:orika@mellanox.com]
发送时间: 2020年7月5日 19:58
收件人: oulijun <oulijun@huawei.com>; ferruh.yigit@intel.com
抄送: dev@dpdk.org; users@dpdk.org
主题: RE: Questions about rte_flow_create APIs
Hi Oulijun,
First small comment, I think you sent the mail in HTML format,
please next time send it as plain text.
From: oulijun <oulijun@huawei.com<mailto:oulijun@huawei.com>>
Sent: Friday, July 3, 2020 9:45 AM
To: Ori Kam <orika@mellanox.com<mailto:orika@mellanox.com>>; ferruh.yigit@intel.com<mailto:ferruh.yigit@intel.com>
Cc: dev@dpdk.org<mailto:dev@dpdk.org>; users@dpdk.org<mailto:users@dpdk.org>
Subject: Questions about rte_flow_create APIs
Hi, Guys
I am analyzing rte_flow_create API and test and is testing server parametric scenario.
When use testpmd and the following flow creat cmd:
testpmd> flow create 0 ingress pattern end actions rss func simple_xor / end
why the contents of rte_flow_action_rss is not same acquisition method after run the flowing codes.
struct rte_flow_action_rss conf;
rss_conf = action->conf;
the Value of unspecified parameter is not same acquisition method.
The rss_conf.type is default;
The rss_conf.key_len is deault;
The rss_conf.queue_num is deault;
However, the rss_conf.key is random and unpredictable
The result is that when the user does not specify the rss key, the driver will fill a random value into the hardware。
The rss key value found by the user is different from the first value, which results in the user not being able to use it correctly.
I think the reasonable behavior is that either the rss rule was not successfully created or the content of the rss key that was queried has not changed
testpmd> show port 0 rss-hash key
RSS functions:
all ipv4-frag ipv4-other ipv6-frag ipv6-other ip
RSS key:
4439796BB54C5023B675EA5B124F9F30B8A2C03DDFDC4D02A08C9B334AF64A4C05C6FA343958D8557D99583AE138C92E81150366
testpmd> flow create 0 ingress pattern eth / ipv4 / udp / end actions rss types ipv4-udp end queues end / end
Flow rule #0 created
testpmd> show port 0 rss-hash key
RSS functions:
all ipv4-udp udp
RSS key:
74657374706D6427732064656661756C74205253532068617368206B65792C206F7665727269646520697420666F722062657474
What do you think?
[Ori] I think this is a testpmd only issue, since it uses the same structure when it pass it to the pmd.
you can look at it in also in a different way.
1. the application create first flow using empty rss action, this mean that the flow gets the default RSS functions,
2. the application insert the flow you gave with different RSS function than the original one.
3. the application create a new flow with empty RSS, no the flow is created using the new RSS function and not the old one.
So I don’t think this is a true issue.
Best,
Ori
Thanks
Lijun Ou
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-07-06 10:59 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-03 6:44 [dpdk-dev] Questions about rte_flow_create APIs oulijun
2020-07-05 11:58 ` Ori Kam
2020-07-06 10:59 ` [dpdk-dev] 答复: " oulijun
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).