Re: [dpdk-dev] Questions about rte_flow_create APIs

2020-07-05 Thread Ori Kam
Hi Oulijun,

First small comment, I think you sent the mail in HTML format,
please next time send it as plain text.


From: oulijun 
Sent: Friday, July 3, 2020 9:45 AM
To: Ori Kam ; ferruh.yi...@intel.com
Cc: dev@dpdk.org; us...@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


[dpdk-dev] Questions about rte_flow_create APIs

2020-07-02 Thread oulijun
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