| Message ID | 2601191342CEEE43887BDE71AB977258214306FB@irsmsx105.ger.corp.intel.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id 6AD4C9A8F; Wed, 20 May 2015 16:28:36 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id A9F2C5947 for <dev@dpdk.org>; Wed, 20 May 2015 16:28:34 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 20 May 2015 07:28:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,464,1427785200"; d="scan'208";a="697796145" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga001.jf.intel.com with ESMTP; 20 May 2015 07:28:09 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.73]) by IRSMSX101.ger.corp.intel.com ([169.254.1.217]) with mapi id 14.03.0224.002; Wed, 20 May 2015 15:28:07 +0100 From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com> To: Zi Hu <huzilucky@gmail.com>, "dev@dpdk.org" <dev@dpdk.org> Thread-Topic: [dpdk-dev] DPDK ACL bug? pkt matches the wrong ACL rule. Thread-Index: AdCTCQqz8MgmwDZ5T9uZEEjE55zbog== Date: Wed, 20 May 2015 14:28:06 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258214306FB@irsmsx105.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Ananyev, Konstantin
May 20, 2015, 2:28 p.m. UTC
Hi Zi, > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zi Hu > Sent: Friday, May 15, 2015 1:27 AM > To: dev@dpdk.org > Subject: [dpdk-dev] DPDK ACL bug? pkt matches the wrong ACL rule. > > 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 I think I found the culprit. Problem is that acl_merge_trie() sometimes is too aggressive in trying to conserve some space at build time. So didn't duplicate a node, even when it should. Could you try a patch below? Thanks Konstantin Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com> --- lib/librte_acl/acl_bld.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
Comments
Hi, Konstantin, The patch does fix the bug with the my test rule/trace file. I will do a little bit more test later to verify that. thanks a lot. -Zi On Wed, May 20, 2015 at 7:28 AM, Ananyev, Konstantin < konstantin.ananyev@intel.com> wrote: > > Hi Zi, > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zi Hu > > Sent: Friday, May 15, 2015 1:27 AM > > To: dev@dpdk.org > > Subject: [dpdk-dev] DPDK ACL bug? pkt matches the wrong ACL rule. > > > > 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 > > I think I found the culprit. > Problem is that acl_merge_trie() sometimes is too aggressive in trying to > conserve some space at build time. > So didn't duplicate a node, even when it should. > Could you try a patch below? > Thanks > Konstantin > > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com> > --- > lib/librte_acl/acl_bld.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/lib/librte_acl/acl_bld.c b/lib/librte_acl/acl_bld.c > index a406737..92a85df 100644 > --- a/lib/librte_acl/acl_bld.c > +++ b/lib/librte_acl/acl_bld.c > @@ -1044,9 +1044,7 @@ acl_merge_trie(struct acl_build_context *context, > * a subtree of the merging tree (node B side). Otherwise, > * just use node A. > */ > - if (level > 0 && > - node_a->subtree_id != > - (subtree_id | RTE_ACL_SUBTREE_NODE)) { > + if (level > 0) { > node_c = acl_dup_node(context, node_a); > node_c->subtree_id = subtree_id | RTE_ACL_SUBTREE_NODE; > } > -- > 1.8.5.3 > >
> From: Zi Hu [mailto:huzilucky@gmail.com] > Sent: Wednesday, May 20, 2015 6:18 PM > To: Ananyev, Konstantin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] DPDK ACL bug? pkt matches the wrong ACL rule. > > Hi, Konstantin, > The patch does fix the bug with the my test rule/trace file. > I will do a little bit more test later to verify that. > thanks a lot. > -Zi Great :) Thanks Konstantin > > On Wed, May 20, 2015 at 7:28 AM, Ananyev, Konstantin <konstantin.ananyev@intel.com> wrote: > > Hi Zi, > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zi Hu > > Sent: Friday, May 15, 2015 1:27 AM > > To: dev@dpdk.org > > Subject: [dpdk-dev] DPDK ACL bug? pkt matches the wrong ACL rule. > > > > 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 > > I think I found the culprit. > Problem is that acl_merge_trie() sometimes is too aggressive in trying to conserve some space at build time. > So didn't duplicate a node, even when it should. > Could you try a patch below? > Thanks > Konstantin > > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com> > --- > lib/librte_acl/acl_bld.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/lib/librte_acl/acl_bld.c b/lib/librte_acl/acl_bld.c > index a406737..92a85df 100644 > --- a/lib/librte_acl/acl_bld.c > +++ b/lib/librte_acl/acl_bld.c > @@ -1044,9 +1044,7 @@ acl_merge_trie(struct acl_build_context *context, > * a subtree of the merging tree (node B side). Otherwise, > * just use node A. > */ > - if (level > 0 && > - node_a->subtree_id != > - (subtree_id | RTE_ACL_SUBTREE_NODE)) { > + if (level > 0) { > node_c = acl_dup_node(context, node_a); > node_c->subtree_id = subtree_id | RTE_ACL_SUBTREE_NODE; > } > -- > 1.8.5.3
diff --git a/lib/librte_acl/acl_bld.c b/lib/librte_acl/acl_bld.c index a406737..92a85df 100644 --- a/lib/librte_acl/acl_bld.c +++ b/lib/librte_acl/acl_bld.c @@ -1044,9 +1044,7 @@ acl_merge_trie(struct acl_build_context *context, * a subtree of the merging tree (node B side). Otherwise, * just use node A. */ - if (level > 0 && - node_a->subtree_id != - (subtree_id | RTE_ACL_SUBTREE_NODE)) { + if (level > 0) { node_c = acl_dup_node(context, node_a); node_c->subtree_id = subtree_id | RTE_ACL_SUBTREE_NODE; }