From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0052.outbound.protection.outlook.com [104.47.40.52]) by dpdk.org (Postfix) with ESMTP id 5C3ECB6D for ; Wed, 8 Feb 2017 19:44:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iextrading.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E3POj8Yp2D6yNB8mVW8u0m5KJSXwRQpVg2EsxGB+mfQ=; b=zavuJrTpVBdrcg0KhK6vUIuLRce7wZkE/ykXULq4Y/6t4FTFYswlYFK1lBw/YADnuaOQutDZsMncg9WBhdMkQhr28rDiCDZrc164fUZeQ9eog1Txly9neGHDmRkJcMRmsxpr40tC5Qa5kpMhNiX0W3KOozvIovTuBkM/0XjbZ/c= Received: from BN6PR1601MB1316.namprd16.prod.outlook.com (10.172.108.138) by BN6PR1601MB1316.namprd16.prod.outlook.com (10.172.108.138) 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:44:56 +0000 Received: from BN6PR1601MB1316.namprd16.prod.outlook.com ([10.172.108.138]) by BN6PR1601MB1316.namprd16.prod.outlook.com ([10.172.108.138]) with mapi id 15.01.0888.026; Wed, 8 Feb 2017 18:44:56 +0000 From: James Cape To: "Wu, Xiaoban" , "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: AQHSgd3hXVX5MzI8q0mEA977lXuJEqFfIWcugABKdk2AAAaAYg== Date: Wed, 8 Feb 2017 18:44:56 +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=james.cape@iextrading.com; x-originating-ip: [25.173.23.4] x-ms-office365-filtering-correlation-id: bae91e87-3362-4d03-c1fe-08d450529409 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN6PR1601MB1316; x-microsoft-exchange-diagnostics: 1; BN6PR1601MB1316; 7:GYNJVyfk12uddC0vmQ1XaIN0u3Z1Xb2BLPjJfgncOCEhyIru6qzGmPZJpRmFc6uXE/C74S9e+8ZfQdJk5KNZqD26+aqSZxaHe1r8MKu19U+iwzPgVCDKCJcXhs0TszZ7pRO+mn4XRr3l5hTb+nys6ZmFTCoom9b0KFlaEJ+hVAfR+eDVf5Q0yrNUQT3HCRnlH5T09c4wOCk0Sr12PLJ78HOM/ZIxC5gtf3fF7FGP7ZKuuFkhNzT6SHVCBADEWW3KS5ezo0YcXeFWlGmDbtDK5H5vG3XJmi2alX8zD7ia6PvRtL9gk8cYwEB90Cc8U0pfFDw+CjtUfC2eaZZJKr9NpwIW9eW3gBwCXJzPleQzqw0TyaxF6bJC15rLC2QJkTu9mwrHVqmL9FmKk9LN4J7WCqTFwrgG9L3BH8bNN1i2bVctUsbTTYDMC+O2k+1jayLEO5QstuYllpiVh/cUse8unTC0QwIzwnmlbIWvge5iv98UAnh3fTLjCCKGllSWjr8PDXhW9e5OL6olQldMH3XjXQ==; 20:OQzV9vpZiLHWPpWkaQpn6QDON3UFh0MeWyU3Ldx9V9xkFaCdid9ZQ/0oETC+fEE1jaD8FEK0+C2+isOMSvHOimB1W+ZMcrTeV04CIqFyXftCxlg/1EsnXI3/4R93O25S/HefAGoO0FmwFxShxEaWZY7F2mf22iDsX4dEUK57CWI= 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)(5005006)(20170203043)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123558025)(20161123562025)(6072148); SRVR:BN6PR1601MB1316; BCL:0; PCL:0; RULEID:; SRVR:BN6PR1601MB1316; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39830400002)(39410400002)(39450400003)(199003)(45984002)(377454003)(189002)(50986999)(189998001)(229853002)(2900100001)(33656002)(6116002)(53546003)(102836003)(9686003)(3846002)(122556002)(5660300001)(3660700001)(6436002)(6246003)(19627405001)(3280700002)(606005)(2906002)(733005)(77096006)(53936002)(68736007)(2171002)(6506006)(97736004)(92566002)(2501003)(7696004)(106356001)(99286003)(25786008)(74316002)(8656002)(86362001)(2950100002)(106116001)(105586002)(55016002)(7906003)(7736002)(236005)(8676002)(6306002)(66066001)(81166006)(101416001)(8936002)(76176999)(54896002)(38730400002)(81156014)(54356999)(7099028); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1601MB1316; H:BN6PR1601MB1316.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: iextrading.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: iextrading.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2017 18:44:56.5378 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b0d01693-bd9f-4234-9888-57e53b52d8ed X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1601MB1316 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:45:00 -0000 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