From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 994CDB5B7 for ; Mon, 16 Feb 2015 10:56:45 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP; 16 Feb 2015 01:52:26 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,586,1418112000"; d="scan'208";a="528100880" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by orsmga003.jf.intel.com with ESMTP; 16 Feb 2015 01:47:53 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.117]) by IRSMSX108.ger.corp.intel.com ([169.254.11.218]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 09:56:20 +0000 From: "Ananyev, Konstantin" To: "yuzhichang_scl@hotmail.com" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] ACL lookup doesn't work for some schemes Thread-Index: AQHQSQB5HnFgGDtmC0yhuvSeRcsoDJzzCdcw Date: Mon, 16 Feb 2015 09:56:19 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258213EC8FE@irsmsx105.ger.corp.intel.com> References: In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] ACL lookup doesn't work for some schemes 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: Mon, 16 Feb 2015 09:56:46 -0000 Hi > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of ??? > Sent: Sunday, February 15, 2015 9:19 AM > To: dev@dpdk.org > Subject: [dpdk-dev] ACL lookup doesn't work for some schemes >=20 > Hi, I noticed that ACL lookup doesn't work for some schemes.1. If the = first field is not uint8_t, even all fields are wildcard, lookup > doesn't find the matching rule. See acl_8last.c.2. I prepended a uint8_t = field, keep other fields be wildcard, lookup returns the correct > result. See acl_8last2.c3. Then I change last field from 8bitmask_WILDCAR= D to 8bitmask(1, 0x1) (matches odd numbers) or 8bitmask(0, > 0x1) (match even numbers), lookup doesn't return the correct. See acl_8la= st3.c. And I noticed the similar behavior for uint16_t > ranges(date doesn't match 0-0x8000 nor 0x8001-0xffff). Above behaviors= are tricky. Does ACL do some undocumented assumptions > or the table schema? Regards,Zhichang Yu Yes, right now, libtre_acl to work correctly first field has to be 1B long = and all subsequent grouped into sets of 4 consecutive bytes. I thought we have it documented into our PG, ACL section: http://dpdk.org/doc/guides/prog_guide/packet_classif_access_ctrl.html Though re-reading it again: "For performance reasons, the inner loop of the search function is unrolled= to process four input bytes at a time. This requires the input to be group= ed into sets of 4 consecutive bytes. The loop processes the first input byt= e as part of the setup and then subsequent bytes must be in groups of 4 con= secutive bytes." It probably not very clear and need to be explained in more details. Will update the doc. Konstantin