* Re: [dpdk-dev] DPDK ACL bug? pkt matches the wrong ACL rule.
@ 2015-05-20 14:28 Ananyev, Konstantin
2015-05-20 17:17 ` Zi Hu
0 siblings, 1 reply; 5+ messages in thread
From: Ananyev, Konstantin @ 2015-05-20 14:28 UTC (permalink / raw)
To: Zi Hu, dev
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] DPDK ACL bug? pkt matches the wrong ACL rule.
2015-05-20 14:28 [dpdk-dev] DPDK ACL bug? pkt matches the wrong ACL rule Ananyev, Konstantin
@ 2015-05-20 17:17 ` Zi Hu
[not found] ` <2601191342CEEE43887BDE71AB97725821430903@irsmsx105.ger.corp.intel.com>
0 siblings, 1 reply; 5+ messages in thread
From: Zi Hu @ 2015-05-20 17:17 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: dev
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
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] DPDK ACL bug? pkt matches the wrong ACL rule.
[not found] ` <2601191342CEEE43887BDE71AB97725821430903@irsmsx105.ger.corp.intel.com>
@ 2015-05-21 9:41 ` Ananyev, Konstantin
0 siblings, 0 replies; 5+ messages in thread
From: Ananyev, Konstantin @ 2015-05-21 9:41 UTC (permalink / raw)
To: Zi Hu (huzilucky@gmail.com); +Cc: dev
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dpdk-dev] DPDK ACL bug? pkt matches the wrong ACL rule.
2015-05-15 0:27 Zi Hu
@ 2015-05-15 10:10 ` Ananyev, Konstantin
0 siblings, 0 replies; 5+ messages in thread
From: Ananyev, Konstantin @ 2015-05-15 10:10 UTC (permalink / raw)
To: Zi Hu, dev
Hi Zi,
> -----Original Message-----
> 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?
Indeed, that looks like a bug.
Will have a look.
Konstantin
>
> thanks
> -Zi
^ permalink raw reply [flat|nested] 5+ messages in thread
* [dpdk-dev] DPDK ACL bug? pkt matches the wrong ACL rule.
@ 2015-05-15 0:27 Zi Hu
2015-05-15 10:10 ` Ananyev, Konstantin
0 siblings, 1 reply; 5+ messages in thread
From: Zi Hu @ 2015-05-15 0:27 UTC (permalink / raw)
To: dev
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-05-21 9:41 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-20 14:28 [dpdk-dev] DPDK ACL bug? pkt matches the wrong ACL rule Ananyev, Konstantin
2015-05-20 17:17 ` Zi Hu
[not found] ` <2601191342CEEE43887BDE71AB97725821430903@irsmsx105.ger.corp.intel.com>
2015-05-21 9:41 ` Ananyev, Konstantin
-- strict thread matches above, loose matches on Subject: below --
2015-05-15 0:27 Zi Hu
2015-05-15 10:10 ` Ananyev, Konstantin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).