[dpdk-dev] rte_acl test-acl app
Ananyev, Konstantin
konstantin.ananyev at intel.com
Tue Oct 28 12:51:15 CET 2014
Hi Erik,
> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Erik Ziegenbalg
> Sent: Saturday, October 25, 2014 4:19 AM
> To: dev at 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
More information about the dev
mailing list