From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0040.outbound.protection.outlook.com [104.47.41.40]) by dpdk.org (Postfix) with ESMTP id B667E9E7 for ; Wed, 8 Feb 2017 22:59:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=studentuml.onmicrosoft.com; s=selector1-student-uml-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QeLT067NUqN1g+e7ylTyEW69a88eVlHVgQfetSb03yw=; b=iniJ8C5o2Bat3/BI10lLIAkhGGb2olWYsNU/520PyadfzageUZjGdCDeavLTk7rCCo02GK6CNdFtLoNwojlmkr/19VoMSDKxrZkx5xlwBKOrBEAb0XG23TIF/1JIhjhS2ZI0ZPu9s54urro+9Crbluc2WucGLh2yNAtVNM9zo8A= Received: from BN6PR02MB2706.namprd02.prod.outlook.com (10.175.95.20) by BN6PR02MB2707.namprd02.prod.outlook.com (10.175.95.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 8 Feb 2017 21:59:24 +0000 Received: from BN6PR02MB2706.namprd02.prod.outlook.com ([10.175.95.20]) by BN6PR02MB2706.namprd02.prod.outlook.com ([10.175.95.20]) with mapi id 15.01.0888.026; Wed, 8 Feb 2017 21:59:23 +0000 From: "Wu, Xiaoban" To: James Cape , "users@dpdk.org" Thread-Topic: [dpdk-users] A confusion caused by the inconsistency in the source code of acl_gen.c. A possible bug? Thread-Index: AQHSgd3hXVX5MzI8q0mEA977lXuJEqFfIWcugABKdk2AAAaAYoAAMAEB Date: Wed, 8 Feb 2017 21:59:23 +0000 Message-ID: References: , , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xiaoban_Wu@student.uml.edu; x-originating-ip: [25.175.94.132] x-ms-office365-filtering-correlation-id: eca3d2cf-e751-41ee-5054-08d4506dbe2f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR02MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR02MB2707; 7:Hn9vq1sDoMwZZ5qFrz8P/Bxf2WpXcwXM6im3vYEnVSarBamm3LednWKA6pQYmrzWJalhZrIl/xAXIZ6gvosKqAhKcR9WQ4xljAUlS0zU4kVtPiqOcuiaILvfguwioWrXPSrzmRgnw/XeVG2I0CHjsSw8T4LihzkF0KnT8TFZuKg3fuCPUvZGyTSXt6OiVvuQhS2DrdWDDpAeJ846YiYFsXQNkGnH/OyCX3ITL4mS7cmFaX2slKG0gpeuBJ0RMJD/LHAra8K/APGWwI9nJNQSM6SqP+vGNmPiM8D5ha2TUvFuUbptDUwvkOiNpd+6fvcjyrXXFIkwMKpj4LJY85fb85RoL5OJNxYvPCKvMNUB079c0e4sVXb4Ydfyv1ROHPuA0STPEtq4jamBieD1anMmuQG425Zrjd2emERmAVlpgtufa2gxunj+VtayHGqnrN0+z+H6nfozIClSc/htBp+u9fRgIULmZnB4X7i6coMfjYfpnc3wM2QjLLZffE2JEVNxXR0wMjJlBzSm6R2iwXFIzA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(192823040165218)(269151656437849); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(20170203043)(2017020702029)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(6072148); SRVR:BN6PR02MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR02MB2707; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(199003)(377454003)(45984002)(6306002)(189998001)(6436002)(3280700002)(77096006)(33656002)(2906002)(7906003)(97736004)(53936002)(54356999)(7736002)(75432002)(74316002)(101416001)(229853002)(54896002)(99286003)(102836003)(8676002)(88552002)(6116002)(68736007)(9686003)(55016002)(76176999)(50986999)(6506006)(25786008)(8936002)(606005)(236005)(733005)(66066001)(3846002)(81166006)(92566002)(3660700001)(81156014)(7696004)(2950100002)(122556002)(6246003)(19627405001)(42882006)(5660300001)(105586002)(2900100001)(86362001)(93886004)(53546003)(106116001)(106356001)(38730400002)(2501003)(7099028); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR02MB2707; H:BN6PR02MB2706.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: student.uml.edu does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: student.uml.edu X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2017 21:59:23.6349 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4c25b8a6-17f7-46f9-83f0-54734ab81fb1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR02MB2707 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] A confusion caused by the inconsistency in the source code of acl_gen.c. A possible bug? X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 21:59:26 -0000 Dear James, If it is only these two for-loops, then indeed the dfa[128] is never checke= d against the index, and it might be the problem. But, before these two for-loops, there is one assignment index =3D dfa[128]; *node_a++ =3D index; for (x =3D QRANGE_MIN + 1; x < UINT8_MAX + 1; x++) { if (dfa[x] !=3D index) { index =3D dfa[x]; *node_a++ =3D index; node->transitions[m++] =3D (uint8_t)(x - 1); } } for (x =3D 0; x < INT8_MAX + 1; x++) { if (dfa[x] !=3D index) { index =3D dfa[x]; *node_a++ =3D index; node->transitions[m++] =3D (uint8_t)(x - 1); } } for (; m < RTE_ACL_QUAD_SIZE; m++) node->transitions[m] =3D INT8_MAX; Hence, it starts with the comparison between dfa[128] and dfa[129], and fin= ally ends up with the comparison between index and dfa[127]. The only thing= left behind is the comparison between index and dfa[128], but for the purp= ose of this part of the codes, we don't need to have such comparison. Actually, since this part is used to generate several ranges (maximum 4) fo= r transition and dfa[128] has been already written into the transition targ= et (*node_a++ =3D index), and with "node->transitions[m] =3D INT8_MAX;" for= completion, so I think logically it is correct. Once again, thanks very much for clearing off my confusion. Best wishes, Xiaoban ________________________________ From: James Cape Sent: Wednesday, February 8, 2017 1:44:56 PM To: Wu, Xiaoban; users@dpdk.org Subject: Re: [dpdk-users] A confusion caused by the inconsistency in the so= urce code of acl_gen.c. A possible bug? Please note there's still a bug in this function if dfa[128] is not some ki= nd of magic value, because that position will never be checked against the = "index" variable. James Cape Platform Team IEX Group, Inc. | 4 World Trade Center, 150 Greenwich St, 44th Floor, New= York, NY 10007 | w. 646.343.2242 | www.iextrading.com ________________________________ From: Wu, Xiaoban Sent: Wednesday, February 8, 2017 1:41:03 PM To: James Cape; users@dpdk.org Subject: Re: [dpdk-users] A confusion caused by the inconsistency in the so= urce code of acl_gen.c. A possible bug? Dear James, Thank you very much for your reply. You are right, I am so sorry that I did= not pay attention to the difference between "x < UINT8_MAX + 1" and "x < I= NT8_MAX + 1". The two for-loops will never overlap. The confusion now is cl= eared off. Best wishes, Xiaoban ________________________________ From: James Cape Sent: Wednesday, February 8, 2017 9:18:43 AM To: Wu, Xiaoban; users@dpdk.org Subject: Re: [dpdk-users] A confusion caused by the inconsistency in the so= urce code of acl_gen.c. A possible bug? [Disclaimer: I'm not at all familiar with this code, or what it's doing, an= d I'm also probably an idiot [?] ] I can't answer your specific question, but the loops aren't overlapping bec= ause QRANGE_MIN is defined as 0x80. However, it also looks like it's never = going to check the (dfa[0x80] !=3D index) case, because the +1's make the l= oops [0x081 - 0x100), and [0x00 - 0x80). James Cape Platform Team IEX Group, Inc. | 4 World Trade Center, 150 Greenwich St, 44th Floor, New= York, NY 10007 | w. 646.343.2242 | www.iextrading.com ________________________________ From: users on behalf of Wu, Xiaoban Sent: Wednesday, February 8, 2017 3:26:14 AM To: users@dpdk.org Subject: [dpdk-users] A confusion caused by the inconsistency in the source= code of acl_gen.c. A possible bug? Dear DPDK users, I have been reading and studying the source codes of the librte_acl, since = I am very curious to know how to algorithmically implement a fast lookup pr= ocess. When I read the function acl_add_ptrs() in the acl_gen.c, there is one comm= ent saying that /* * Rather than going from 0 to 256, the range count and * the layout are from 80-ff then 0-7f due to signed compare * for SSE (cmpgt). */ However, in the following codes, it is for (x =3D QRANGE_MIN + 1; x < UINT8_MAX + 1; x++) { if (dfa[x] !=3D index) { index =3D dfa[x]; *node_a++ =3D index; node->transitions[m++] =3D (uint8_t)(x - 1); } } for (x =3D 0; x < INT8_MAX + 1; x++) { if (dfa[x] !=3D index) { index =3D dfa[x]; *node_a++ =3D index; node->transitions[m++] =3D (uint8_t)(x - 1); } } As you can see that there are two for-loops, and the second for-loop includ= e the first for-loop. And, this is not consistent with the comment. If the = comment is followed, in the second for-loop, it should be "for (x =3D 0; x = < QRANGE_MIN + 1; x++)", if we assume QRANGE_MIN is ff? Moreover, due to that the first for-loop is included in the second for-loop= and the "m" variable is increased by 1 whenever the if-statement is true, = I am thinking about a case in which during the first for-loop, the "m" is i= ncreased by 3, hence after the second for-loop, the "m" is at least 6, this= will finally break the check RTE_ACL_VERIFY(m <=3D RTE_ACL_QUAD_SIZE) in t= he following code, since RTE_ACL_QUAD_SIZE is 4. I am wondering if this cas= e will ever happen? Am I missing something here? Thanks very much for your help. Best wishes, Xiaoban This email is subject to important notices and disclaimers regarding legal = privilege, confidentiality, viruses and monitoring, available at www.iextra= ding.com/electroniccommunications This email is subject to important notices and disclaimers regarding legal = privilege, confidentiality, viruses and monitoring, available at www.iextra= ding.com/electroniccommunications