From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0086.outbound.protection.outlook.com [104.47.38.86]) by dpdk.org (Postfix) with ESMTP id 6D26F282 for ; Wed, 8 Feb 2017 19:41:05 +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=txV16b5lCKf1sD7Y+l1OIPJC/0eO97muVk9xzTDm9eQ=; b=AnSROirhHSnfoQEhV/h7MgF9Xpcl3pHX6acz2bo5PMcZHe/VLb28zXLFi9H2rzJrjQGGVcjwR2gd08n7oF949qmE2EiC4kHaQvUkribEGovWKwNfloKNhd/YD6DtVa5QDbdNbe4ssTPjt8iRKitpJf4PETxhyzBvGFO7pIE+FBo= 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 18:41:04 +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 18:41:04 +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: AQHSgd3hXVX5MzI8q0mEA977lXuJEqFfIWcugABKdk0= Date: Wed, 8 Feb 2017 18:41:03 +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: 17a1641b-d565-4ed5-c9bc-08d45052095d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR02MB2707; x-microsoft-exchange-diagnostics: 1; BN6PR02MB2707; 7:0n8Cthn7CsXLCTpvq5VDDRCRtTh1CHs0TjC429IAYYE6T+FlLsI/GfXGp+yuDZvoimnVhosqTv3yF214GSg7mTg/0n1RiIROT6+rPMt+39cjNs8s7mxIDnZObB74PpIQhfKhiJIlq72ZCk0UrbBxc4aPxQnlmtnmTDU0CaEu99hbycf+9pTSQNInhCCJJxN/zD1Pv8jNQqc4IwA+EaL/phJI/dGNwOhTwdzFXRRu8c+kNdeTk9zMTvmu22hF+ft60cKweGRuuiXNggUMLPT/aXAMpvLjIat6Z4INSMIrIGeoIn0/zU9CT7q1EElyJxlqdlupZ5Gl07/HyWnI09BQL5fe4IrcQT2VKy32ofvm6gA5K4KluVgV9OQH7mCSoSQlmLjpGd1fgp5g/d1gUso3u2bED9zwLMVTCYbLQ0wUOguPkkPTAE1UOWFr+g17FeiwR+zS13ow6YsP08Jvyw/7wACDCLn6tYYYvf5n+2xfB/nII31S6fcgL98vOYFPWNxv2CvBeuLN1kjp9iGu65Q+OA== 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)(2017020702029)(20170203043)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558025)(6072148); SRVR:BN6PR02MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR02MB2707; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(199003)(45984002)(377454003)(189002)(2950100002)(122556002)(42882006)(6246003)(92566002)(3660700001)(7696004)(81156014)(81166006)(19627405001)(53546003)(86362001)(2501003)(106356001)(38730400002)(106116001)(105586002)(2900100001)(5660300001)(53936002)(97736004)(7736002)(2906002)(7906003)(33656002)(101416001)(229853002)(75432002)(74316002)(189998001)(6306002)(3280700002)(77096006)(6436002)(6506006)(25786008)(8936002)(50986999)(76176999)(606005)(733005)(236005)(3846002)(66066001)(99286003)(8676002)(88552002)(102836003)(54356999)(54896002)(9686003)(55016002)(6116002)(68736007)(7099028); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR02MB2707; H:BN6PR02MB2706.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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 18:41:03.8612 (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 18:41:05 -0000 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