[dpdk-dev] rte_acl test-acl app

[dpdk-dev] rte_acl test-acl app

[Erik Ziegenbalg]

Hi everyone,

I am having trouble to successfully perform a packet classification
using the rte_acl test app. I have my rules.acl and trace.acl files as
follows:

rules.acl:
@192.168.0.0/24 192.168.0.0/24 400 : 500 1000 : 2000 6/0xff

trace.acl:
192.168.0.5 192.168.0.9 450 1002 0x06

However, the result always comes up as 4294967295 (xFFFFFFFF). I have
dug through the code quite a bit to follow and see what is going on, but
not sure where I went wrong.

Any help on how the rte_acl_classify function works would be much
appreciated. In understand that the data for rte_acl_classify is a
uint32_t ** and I double checked to make sure I'm passing along proper
values. Is xFFFFFFFF the expected result? If so, I am getting the same
for packets that should not match.

Thank you,
Erik Ziegenbalg

Re: [dpdk-dev] rte_acl test-acl app

[Ananyev, Konstantin]

Hi Erik,

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Erik Ziegenbalg
> Sent: Saturday, October 25, 2014 4:19 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] rte_acl test-acl app
> 
> Hi everyone,
> 
> I am having trouble to successfully perform a packet classification
> using the rte_acl test app. I have my rules.acl and trace.acl files as
> follows:
> 
> rules.acl:
> @192.168.0.0/24 192.168.0.0/24 400 : 500 1000 : 2000 6/0xff
> 
> trace.acl:
> 192.168.0.5 192.168.0.9 450 1002 0x06
> 
> However, the result always comes up as 4294967295 (xFFFFFFFF). I have
> dug through the code quite a bit to follow and see what is going on, but
> not sure where I went wrong.
> 
> Any help on how the rte_acl_classify function works would be much
> appreciated. In understand that the data for rte_acl_classify is a
> uint32_t ** and I double checked to make sure I'm passing along proper
> values. Is xFFFFFFFF the expected result? If so, I am getting the same
> for packets that should not match.

That's strange: for me latest code with dpdk.org works as expected:

# cat ./test/rule1
@192.168.0.0/24 192.168.0.0/24 400 : 500 1000 : 2000 6/0xff
# cat ./test/trace1
0xc0a80005 0xc0a80009 450 1002 0x06

# ./dpdk.org/x86_64-native-linuxapp-gcc/app/testacl  -n 2 -c 4 --   --rulesf=./test/rule1    --tracef=./test/trace1
....
ipv4_5tuple: 1, category: 0, result: 0
...
i.e: rule #0 matches given flow, as expected. 

Do you use testacl or some other app?

Konstantin

> 
> Thank you,
> Erik Ziegenbalg

[dpdk-dev] rte_acl test-acl app

[Erik Ziegenbalg]

Hi everyone,

I am having trouble to successfully perform a packet classification
using the rte_acl test app. I have my rules.acl and trace.acl files as
follows:

rules.acl:
@192.168.0.0/24 192.168.0.0/24 400 : 500 1000 : 2000 6/0xff

trace.acl:
192.168.0.5 192.168.0.9 450 1002 0x06

However, the result always comes up as 4294967295 (xFFFFFFFF). I have
dug through the code quite a bit to follow and see what is going on, but
not sure where I went wrong.

Any help on how the rte_acl_classify function works would be much
appreciated. In understand that the data for rte_acl_classify is a
uint32_t ** and I double checked to make sure I'm passing along proper
values. Is xFFFFFFFF the expected result? If so, I am getting the same
for packets that should not match.

Thank you,
Erik Ziegenbalg