From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Karmarkar Suyash <skarmarkar@sonusnet.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "Dey, Souvik" <sodey@sonusnet.com>,
"Patil, PraveenKumar" <ppatil@sonusnet.com>
Subject: Re: [dpdk-dev] Bug in IPACL library of DPDK-1.6.0
Date: Tue, 14 Oct 2014 14:44:37 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB97725821393825@IRSMSX105.ger.corp.intel.com> (raw)
In-Reply-To: <F68D47BAAB943145B18773EDECE588EE0DC00FB2@inba-mail02.sonusnet.com>
> From: Karmarkar Suyash [mailto:skarmarkar@sonusnet.com]
> Sent: Tuesday, October 14, 2014 1:36 PM
> To: Ananyev, Konstantin; dev@dpdk.org
> Cc: Dey, Souvik; Patil, PraveenKumar
> Subject: RE: Bug in IPACL library of DPDK-1.6.0
>
> There are two user defined ACL rules and they are added with just different priority -
>
> 1. And all other fields are wild card:
> * SOURCE IP and DEST IP = wild card (*)
> * LIF_GRP_INFO_FIELD_IPV6 = wild card (*)
> * PORTS = wild card (*)
> 2. Only next header protocol is specified = ICMPv6 (58)
> 3. Priority is different. But the one with lower priority is returned during lookup.
>
Hm, I tried what your described - works ok for me.
Are you saying you are still using DPDK 1.6 IPL?
If so, can you upgrade to 1.7 and give it another try?
There was one bug fixed in 1.7 very similar to what you describing:
http://dpdk.org/ml/archives/dev/2014-June/003198.html
Konstantin
> The structure is -
>
> enum
> {
> NEXT_HDR_FIELD_IPV4, //8
> IPSRC_FIELD_IPV4, //src ip (32)
> IPDST_FIELD_IPV4, //dst ip (32)
> PORTS_FIELD_IPV4, // src port (16) + dest port (16) => 32
> LIF_GRP_INFO_FIELD_IPV4, //lif group (16) + lif Id (16) => 32
> ADDR_CTX_FIELD_IPV4, //addr context (32)
> NUM_FIELDS_IPV4
> };
>
>
>
> struct rte_acl_field_def ipv6_defs[NUM_FIELDS_IPV6] = {
> {
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint8_t),
> .field_index = NEXT_HDR_FIELD_IPV6,
> .input_index = NEXT_HDR_FIELD_IPV6,
> .offset = offsetof(struct ipv6_hdr, proto),
> },
>
> ///source ip
> {
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPSRC_FIELD0_IPV6,
> .input_index = IPSRC_FIELD0_IPV6,
> .offset = offsetof(struct ipv6_hdr, src_addr),
> },
> {
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPSRC_FIELD1_IPV6,
> .input_index = IPSRC_FIELD1_IPV6,
> .offset = offsetof(struct ipv6_hdr, src_addr) + 1*sizeof (uint32_t),
> },
> {
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPSRC_FIELD2_IPV6,
> .input_index = IPSRC_FIELD2_IPV6,
> .offset = offsetof(struct ipv6_hdr, src_addr) + 2*sizeof (uint32_t),
> },
> {
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPSRC_FIELD3_IPV6,
> .input_index = IPSRC_FIELD3_IPV6,
> .offset = offsetof(struct ipv6_hdr, src_addr) + 3*sizeof (uint32_t),
> },
>
> ///destination ip
> {
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPDST_FIELD0_IPV6,
> .input_index = IPDST_FIELD0_IPV6,
> .offset = offsetof(struct ipv6_hdr, dst_addr),
> },
> {
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPDST_FIELD1_IPV6,
> .input_index = IPDST_FIELD1_IPV6,
> .offset = offsetof(struct ipv6_hdr, dst_addr) + 1*sizeof (uint32_t),
> },
> {
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPDST_FIELD2_IPV6,
> .input_index = IPDST_FIELD2_IPV6,
> .offset = offsetof(struct ipv6_hdr, dst_addr) + 2*sizeof (uint32_t),
> },
> {
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPDST_FIELD3_IPV6,
> .input_index = IPDST_FIELD3_IPV6,
> .offset = offsetof(struct ipv6_hdr, dst_addr) + 3*sizeof (uint32_t),
> },
>
> ///ports
> {
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = PORTS_FIELD_IPV6,
> .input_index = PORTS_FIELD_IPV6,
> .offset = sizeof(struct ipv6_hdr) ,
> },
> //LIF grp and addr ctx
> {
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = LIF_GRP_INFO_FIELD_IPV6,
> .input_index = LIF_GRP_INFO_FIELD_IPV6,
> .offset = sizeof(struct ipv6_hdr) + sizeof (uint32_t),
> },
> {
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = ADDR_CTX_FIELD_IPV6,
> .input_index = ADDR_CTX_FIELD_IPV6,
> .offset = sizeof(struct ipv6_hdr) + 2*sizeof (uint32_t),
> }
> } ;
>
>
>
>
> -----Original Message-----
> From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com]
> Sent: Tuesday, October 14, 2014 4:16 PM
> To: Karmarkar Suyash; dev@dpdk.org
> Cc: Dey, Souvik; Patil, PraveenKumar
> Subject: RE: Bug in IPACL library of DPDK-1.6.0
>
> Hi,
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Karmarkar Suyash
> > Sent: Tuesday, October 14, 2014 10:55 AM
> > To: dev@dpdk.org
> > Cc: Dey, Souvik; Patil, PraveenKumar
> > Subject: [dpdk-dev] Bug in IPACL library of DPDK-1.6.0
> >
> > Hello All,
> >
> > If there are two identical IPv6 rules with source and destination IP
> > addresses as wild card but with different priority, then during lookup always the rule that is added first in TRIE is returned even
> though the second rule that has highest priority.
> >
>
> Could you provide a bit more details how to reproduce the problem:
> - either a rule and trace file to reproduce the problem in testacl (classsbench) format -or some simple code snippet.
>
> Thanks
> Konstantin
>
> > Regards
> > Suyash Karmarkar
>
>
next prev parent reply other threads:[~2014-10-14 14:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-14 9:55 Karmarkar Suyash
2014-10-14 10:45 ` Ananyev, Konstantin
2014-10-14 12:36 ` Karmarkar Suyash
2014-10-14 14:44 ` Ananyev, Konstantin [this message]
2014-10-14 15:06 ` Karmarkar Suyash
2014-10-14 15:17 ` Ananyev, Konstantin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2601191342CEEE43887BDE71AB97725821393825@IRSMSX105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=dev@dpdk.org \
--cc=ppatil@sonusnet.com \
--cc=skarmarkar@sonusnet.com \
--cc=sodey@sonusnet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).