From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from p01c11o148.mxlogic.net (p01c11o148.mxlogic.net [208.65.144.71]) by dpdk.org (Postfix) with ESMTP id 398C97E6E for ; Tue, 14 Oct 2014 16:59:02 +0200 (CEST) Received: from unknown [66.151.187.12] (EHLO smtp.sonusnet.com) by p01c11o148.mxlogic.net(mxl_mta-8.1.0-0) over TLS secured channel with ESMTP id 60c3d345.0.30866.00-253.89806.p01c11o148.mxlogic.net (envelope-from ); Tue, 14 Oct 2014 09:06:47 -0600 (MDT) X-MXL-Hash: 543d3c071acc2e63-aceb668e98379b0ab95fac764e56b8ab0a865515 Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by psmwsonshc02.sonusnet.com (10.176.20.8) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Oct 2014 11:06:44 -0400 Received: from INBA-MAIL02.sonusnet.com ([10.70.51.89]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.03.0181.006; Tue, 14 Oct 2014 20:36:39 +0530 From: Karmarkar Suyash To: "Ananyev, Konstantin" , "dev@dpdk.org" Thread-Topic: Bug in IPACL library of DPDK-1.6.0 Thread-Index: Ac/nlN/T4HWZL3EbQoWoKK2IGfS6ZQABrq6AAAOG40AAAopFUAADEcfw Date: Tue, 14 Oct 2014 15:06:39 +0000 Message-ID: References: <2601191342CEEE43887BDE71AB9772582139376B@IRSMSX105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB97725821393825@IRSMSX105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725821393825@IRSMSX105.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.54.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.1 cv=Y4Lss3uN c=1 sm=1 tr=0 a=OF4WD78bns2OWLoCgEPmtw==] X-AnalysisOut: [:117 a=OF4WD78bns2OWLoCgEPmtw==:17 a=URNJFqk9g_oA:10 a=xvT] X-AnalysisOut: [xkHHju24A:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br] X-AnalysisOut: [6kY4A:10 a=kUVcWBOSAAAA:8 a=YlVTAMxIAAAA:8 a=QyXUC8HyAAAA:] X-AnalysisOut: [8 a=8rWy6zfcAAAA:8 a=B4yeWUKfN-FjofzG3XQA:9 a=ACdt7bsGWzgW] X-AnalysisOut: [uiSG:21 a=XSmIyc7q1lD55WN2:21 a=CjuIK1q_8ugA:10 a=9ZZyOYyq] X-AnalysisOut: [9vMA:10 a=dGJ0OcVc7YAA:10 a=SumTzdpxxCEA:10 a=AOwmXBQAedEA] X-AnalysisOut: [:10] X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2014101412); S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [66.151.187.12] Cc: "Dey, Souvik" , "Patil, PraveenKumar" Subject: Re: [dpdk-dev] Bug in IPACL library of DPDK-1.6.0 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: Tue, 14 Oct 2014 14:59:03 -0000 Hi Konstantin, We did even tried with DPDK-1.7.0 version still we faced the same issue. Regards Suyash Karmarkar -----Original Message----- From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com]=20 Sent: Tuesday, October 14, 2014 8:15 PM To: Karmarkar Suyash; dev@dpdk.org Cc: Dey, Souvik; Patil, PraveenKumar Subject: RE: Bug in IPACL library of DPDK-1.6.0 > 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 >=20 > There are two user defined ACL rules and they are added with just=20 > different priority - >=20 > 1. And all other fields are wild card: > * SOURCE IP and DEST IP =3D wild card (*) > * LIF_GRP_INFO_FIELD_IPV6 =3D wild card (*) > * PORTS =3D wild card (*) > 2. Only next header protocol is specified =3D ICMPv6 (58) 3. Priority is= =20 > different. But the one with lower priority is returned during lookup. >=20 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 - >=20 > 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) =3D> 32 > LIF_GRP_INFO_FIELD_IPV4, //lif group (16) + lif Id (16) =3D> 32 > ADDR_CTX_FIELD_IPV4, //addr context (32) > NUM_FIELDS_IPV4 > }; >=20 >=20 >=20 > struct rte_acl_field_def ipv6_defs[NUM_FIELDS_IPV6] =3D { > { > .type =3D RTE_ACL_FIELD_TYPE_BITMASK, > .size =3D sizeof (uint8_t), > .field_index =3D NEXT_HDR_FIELD_IPV6, > .input_index =3D NEXT_HDR_FIELD_IPV6, > .offset =3D offsetof(struct ipv6_hdr, proto), > }, >=20 > ///source ip > { > .type =3D RTE_ACL_FIELD_TYPE_BITMASK, > .size =3D sizeof (uint32_t), > .field_index =3D IPSRC_FIELD0_IPV6, > .input_index =3D IPSRC_FIELD0_IPV6, > .offset =3D offsetof(struct ipv6_hdr, src_addr), > }, > { > .type =3D RTE_ACL_FIELD_TYPE_BITMASK, > .size =3D sizeof (uint32_t), > .field_index =3D IPSRC_FIELD1_IPV6, > .input_index =3D IPSRC_FIELD1_IPV6, > .offset =3D offsetof(struct ipv6_hdr, src_addr) + 1*sizeof (uint32_= t), > }, > { > .type =3D RTE_ACL_FIELD_TYPE_BITMASK, > .size =3D sizeof (uint32_t), > .field_index =3D IPSRC_FIELD2_IPV6, > .input_index =3D IPSRC_FIELD2_IPV6, > .offset =3D offsetof(struct ipv6_hdr, src_addr) + 2*sizeof (uint32_= t), > }, > { > .type =3D RTE_ACL_FIELD_TYPE_BITMASK, > .size =3D sizeof (uint32_t), > .field_index =3D IPSRC_FIELD3_IPV6, > .input_index =3D IPSRC_FIELD3_IPV6, > .offset =3D offsetof(struct ipv6_hdr, src_addr) + 3*sizeof (uint32_= t), > }, >=20 > ///destination ip > { > .type =3D RTE_ACL_FIELD_TYPE_BITMASK, > .size =3D sizeof (uint32_t), > .field_index =3D IPDST_FIELD0_IPV6, > .input_index =3D IPDST_FIELD0_IPV6, > .offset =3D offsetof(struct ipv6_hdr, dst_addr), > }, > { > .type =3D RTE_ACL_FIELD_TYPE_BITMASK, > .size =3D sizeof (uint32_t), > .field_index =3D IPDST_FIELD1_IPV6, > .input_index =3D IPDST_FIELD1_IPV6, > .offset =3D offsetof(struct ipv6_hdr, dst_addr) + 1*sizeof (uint32_= t), > }, > { > .type =3D RTE_ACL_FIELD_TYPE_BITMASK, > .size =3D sizeof (uint32_t), > .field_index =3D IPDST_FIELD2_IPV6, > .input_index =3D IPDST_FIELD2_IPV6, > .offset =3D offsetof(struct ipv6_hdr, dst_addr) + 2*sizeof (uint32_= t), > }, > { > .type =3D RTE_ACL_FIELD_TYPE_BITMASK, > .size =3D sizeof (uint32_t), > .field_index =3D IPDST_FIELD3_IPV6, > .input_index =3D IPDST_FIELD3_IPV6, > .offset =3D offsetof(struct ipv6_hdr, dst_addr) + 3*sizeof (uint32_= t), > }, >=20 > ///ports > { > .type =3D RTE_ACL_FIELD_TYPE_BITMASK, > .size =3D sizeof (uint32_t), > .field_index =3D PORTS_FIELD_IPV6, > .input_index =3D PORTS_FIELD_IPV6, > .offset =3D sizeof(struct ipv6_hdr) , > }, > //LIF grp and addr ctx > { > .type =3D RTE_ACL_FIELD_TYPE_BITMASK, > .size =3D sizeof (uint32_t), > .field_index =3D LIF_GRP_INFO_FIELD_IPV6, > .input_index =3D LIF_GRP_INFO_FIELD_IPV6, > .offset =3D sizeof(struct ipv6_hdr) + sizeof (uint32_t), > }, > { > .type =3D RTE_ACL_FIELD_TYPE_BITMASK, > .size =3D sizeof (uint32_t), > .field_index =3D ADDR_CTX_FIELD_IPV6, > .input_index =3D ADDR_CTX_FIELD_IPV6, > .offset =3D sizeof(struct ipv6_hdr) + 2*sizeof (uint32_t), > } > } ; >=20 >=20 >=20 >=20 > -----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 >=20 > Hi, >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Karmarkar=20 > > 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=20 > > addresses as wild card but with different priority, then during=20 > > lookup always the rule that is added first in TRIE is returned even > though the second rule that has highest priority. > > >=20 > Could you provide a bit more details how to reproduce the problem: > - either a rule and trace file to reproduce the problem in testacl (class= sbench) format -or some simple code snippet. >=20 > Thanks > Konstantin >=20 > > Regards > > Suyash Karmarkar >=20 >