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
