From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0075.outbound.protection.outlook.com [104.47.33.75]) by dpdk.org (Postfix) with ESMTP id E6851F72 for ; Wed, 8 Feb 2017 15:18:45 +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=0oK0rMWSsbyyNkzAra/MTAS2ZWUH4uQqnPG/QMT6mBU=; b=wZ+j3LXHMpRWLwv5yZUXxg73kPRUjlae7DqnC98rXeES1vIoR+YZsHBx/o4vk5oTzvCS5eOP5MO4mqdKF8H4ZdNVJ6Pzd+c6T2iB1rTBPPnnfJaOzOsF+LDnWEoWZ4KrtkjkWem7evD6LHF09rtFx8QyILUrJqzMUJ5u5FdUtPU= Received: from BN6PR1601MB1316.namprd16.prod.outlook.com (10.172.108.138) by BN6PR1601MB1313.namprd16.prod.outlook.com (10.172.108.135) 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 14:18:43 +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 14:18:43 +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: AQHSgd3hXVX5MzI8q0mEA977lXuJEqFfIWcu Date: Wed, 8 Feb 2017 14:18:43 +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: ad362688-3758-498e-4e2e-08d4502d637f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN6PR1601MB1313; x-microsoft-exchange-diagnostics: 1; BN6PR1601MB1313; 7:TMRvg9GCM7UC/kBBp0i2pnUXwIbkb+WD91KfUfZ5eXmJR9jiu0NVyIr1iiQyEWMx+MOndMmn9EbjVbLLcoPWfoLMbM5H3dLp/Re2ogmaw3lQfLeyK2x75gDGaezkL5O0qmjwExb3U0sDXG9GyIoGs4S+9Y7bHBptqbg1M3kJCxChj2vqJWaQRxFvqE7oE2wM8KcKDaaYHZQnyKpTvNjA63viJLLrw+GYT4tXbmR8zELQ/9gabd2lJjGDHNeKzMdWRNgPf4Qi8yxA29iiNCmql4U1b0ZE9OnmD6yQy3TPiZHLq71zaGlHaI8Ex5QISJl+WdBPkOHQfZ/nCs+URM278xEGi9Po9WDBks93YrG3VvagjsSegr7MuetSWcjdpiMPaiSF9G/6fxLJliqkh/3tRtT3po5jUkbuAKXT/hNEVbp/F7msWOEGpkpwe/Pf4806BwE6odYQglQxkJ60EtnX/c3kJ6Kk8t3nsPj3imIM2T9an9dQ0SQp9DMZ91EgYhigaS80Bzef5L/zjNxCgLij3Q==; 20:wN8L5QgOpSN6BJhGhe3uomZmNYGB6Pruz2iIj7jEqZBkgk5ZAYUzNKQGBtgic7qeBGRolEaI51UPK0E/E3l8s3sjbOiWRuCDupwBmAxKHUzzqIr++WQwefIqQKP+SHsQ0Ib6TtvtHT0upEQVwSCTd4GRWHA/l4EEucNjrxAs7mc= 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)(20170203043)(8121501046)(5005006)(2017020702029)(3002001)(10201501046)(6041248)(20161123564025)(20161123558025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:BN6PR1601MB1313; BCL:0; PCL:0; RULEID:; SRVR:BN6PR1601MB1313; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(39830400002)(39410400002)(189002)(199003)(377454003)(6116002)(86362001)(3846002)(99286003)(3280700002)(55016002)(2900100001)(102836003)(68736007)(50986999)(76176999)(66066001)(189998001)(54356999)(733005)(25786008)(606005)(101416001)(74316002)(53546003)(81166006)(6246003)(81156014)(8676002)(5660300001)(7736002)(9686003)(8656002)(8936002)(7696004)(2501003)(2950100002)(236005)(33656002)(54896002)(6306002)(92566002)(122556002)(6436002)(7906003)(38730400002)(106116001)(53936002)(106356001)(3660700001)(2171002)(229853002)(97736004)(77096006)(2906002)(105586002)(6506006)(7099028); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1601MB1313; H:BN6PR1601MB1316.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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 14:18:43.7198 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b0d01693-bd9f-4234-9888-57e53b52d8ed X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1601MB1313 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 14:18:46 -0000 [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