From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by dpdk.org (Postfix) with ESMTP id B41875A3E for ; Fri, 15 May 2015 02:27:27 +0200 (CEST) Received: by qgg76 with SMTP id 76so19906573qgg.3 for ; Thu, 14 May 2015 17:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XVf1nUtWPbISfATTi/uaQUSTUjrffpwBBT3un4YeKjg=; b=O+IdB9P91revSchq573SOHSQLLcAn6U1awHbkjo6tX3qbdPOC/qorVPKAOFvLcuPsj bBxWJpd1c7Mgv1VgSptkOQSc+CiryqPYVxZrbwVt+xAKAebSY0rAKjki4JqSaC7tQYrz QyfGeobqMNnaUT8CA7hHcQP6BMskdRhoR0BtkEBkbagXO+ByeopqM+D/nfgyjz8BJ1E/ XBDLvuGIWQ8Is5e9K8JWAWgNiq2AXQsqO6Oi8Tvn3DNZ+hfw/DfOk6mF7+N+ONxA4Xmd MfFQBEalpoAcpXmUBhmHuO43UbJ0rxDl1Ka8pFozQ7d4PLGHS5FpaSrUL7zaDXxuQ5x8 jxZA== MIME-Version: 1.0 X-Received: by 10.140.194.141 with SMTP id p135mr9580397qha.44.1431649647268; Thu, 14 May 2015 17:27:27 -0700 (PDT) Received: by 10.229.235.131 with HTTP; Thu, 14 May 2015 17:27:27 -0700 (PDT) Date: Thu, 14 May 2015 17:27:27 -0700 Message-ID: From: Zi Hu To: dev@dpdk.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] DPDK ACL bug? pkt matches the wrong ACL rule. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 00:27:28 -0000 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 @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