[dpdk-dev] DPDK ACL bug? pkt matches the wrong ACL rule.

[Zi Hu <huzilucky@gmail.com>]

Hi, there,

I recently noticed that sometimes packets are matched with the wrong ACL
rules when using the DPDK ACL library.

I tested it with the "testacl" under dpdk/build/app:
Here are my rule file and trace file:
cat test_data/rule1
@192.168.0.0/24 192.168.0.0/24 400 : 500 0 : 52 6/0xff
@192.168.0.0/24 192.168.0.0/24 400 : 500 54 : 65280 6/0xff
@192.168.0.0/24 192.168.0.0/24 400 : 500 0 : 65535 6/0xff

 cat test_data/trace1
0xc0a80005 0xc0a80009 450 53 0x06

I run the test by:
sudo ./testacl -n 2 -c 4 -- --rulesf=./test_data/rule1
--tracef=./test_data/trace1

Result:
.....
acl context <TESTACL>@0x7f5b43effac0
  socket_id=-1
  alg=2
  max_rules=65536
  rule_size=96
  num_rules=3
  num_categories=3
  num_tries=1
ipv4_5tuple: 1, category: 0, result: 1
search_ip5tuples_once(1, 256, sse) returns 1
search_ip5tuples  @lcore 2: 1 iterations, 1 pkts, 1 categories, 21812
cycles, 21812.000000 cycles/pkt


The result shows that the packet matches the second rule,  which is wrong.
The dest port of the pkt is 53, so it should match the third rule.
How possible could it match the second rule?  Anyone see similar situation
before?

Another interesting I found  is that if we make the dest port range to be
54 : 65279 in the second rule (only change 65280 to 65279, all other stuff
remains the same):

cat test_data/rule1
@192.168.0.0/24 192.168.0.0/24 400 : 500 0 : 52 6/0xff
@192.168.0.0/24 192.168.0.0/24 400 : 500 54 : 65279 6/0xff
@192.168.0.0/24 192.168.0.0/24 400 : 500 0 : 65535 6/0xff

Then run the test again, the packet matches the third rule as expected.


This seems really weird to me. Anyone has an explanation for that?

thanks
-Zi