From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0042.outbound.protection.outlook.com [104.47.36.42]) by dpdk.org (Postfix) with ESMTP id BBD4D9E7 for ; Wed, 8 Feb 2017 23:29:33 +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=YflrRzd9socOD4QDfHvmCoYfgkeU+hjUMtf/a6VbNys=; b=rL1iFC0wDtKt6dyd0CDejykhTb9uPBQSAjxh9291e97UrFYbM7Mb+7Ec/985j0WdklmoDo5zSgeHR1OBEYEj/xri7YbPqMA9h3IVB1iBNVUW79wPws1MY/s7Xp1uoBP3Z/ZdCXkMo05wJ2tMIJQiLB9p2yMydnk+FNdtOqD31WI= Received: from BN6PR1601MB1316.namprd16.prod.outlook.com (10.172.108.138) by BN6PR1601MB1314.namprd16.prod.outlook.com (10.172.108.136) 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 22:29:30 +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 22:29:30 +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: AQHSgd3hXVX5MzI8q0mEA977lXuJEqFfIWcugABKdk2AAAaAYoAAMAEBgAAPfaQ= Date: Wed, 8 Feb 2017 22:29:30 +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: 20e51d5a-15b6-4cf2-04aa-08d45071f2fc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN6PR1601MB1314; x-microsoft-exchange-diagnostics: 1; BN6PR1601MB1314; 7:0/ckNvqnwqHFkaZjUxZgcuBTiZuqFFid5PNKuBLPEICm3SdmxTO/PsWx7g3F3M70OC1JGDdbWHckexnzIgnIX5d1YWD+DnAtPafHaIc3pXHpyMxUDGq5ZRHyTXQw8wXsAhKEWrAPracdMK6+l0dFoUa7E0uEdkATCFnPzPPrzJ+13hFFVlzls+d60G1dvjdO29y2YhI16D12EobpDcyUe9Xqg9oxmLJ4xLTh9Qr0UMH3zfy/XyAkQtnJVULfVAbKSppagiQ1EJugwiQHDuKBqSi71ZNZ4DUKV1NYCyPL0rG6KMxJkwcnzYtxN/h7lDaPEOso367Ga7BFcsw+CAlctiGwBYxZWxbd2wht27oZRuko5gg8BXIxIXEG6zhLUNGZpz2bSs6L9sI+bSshUbEyh+MmW0VLfVS/ZMkr8libNGDOdR0zbALYBlSqNPuprIdEVQeBqV48cQblI+mn9dvFRAAzjOxCvIz2rhVbQM+0MqkSz5XkZ/WySO7xTSBUVv/arDrfziuOmMqgSXCDfqXrjw==; 20:LpRYQUYCtN1lc85HzPhkEbepfds4G5ESDwsxEgPxRxahGY3qa6RwTSC9hKwpGKp+KpZgZFXkmsavJXqgz1G2656PmvPwNwyvFqN53DN0AKhN3EqskK5RecmOAmBMaQJCCIyNDR+dL07+faY2IRWmKttfHLLGNbbYUAWYWMlpcmU= 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)(2017020702029)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:BN6PR1601MB1314; BCL:0; PCL:0; RULEID:; SRVR:BN6PR1601MB1314; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39830400002)(39410400002)(39450400003)(199003)(377454003)(45984002)(189002)(733005)(86362001)(93886004)(55016002)(606005)(76176999)(50986999)(54356999)(99286003)(38730400002)(19627405001)(101416001)(8656002)(105586002)(6436002)(106116001)(6116002)(122556002)(102836003)(7736002)(7696004)(66066001)(25786008)(106356001)(33656002)(3846002)(7906003)(2906002)(81156014)(97736004)(3280700002)(81166006)(8936002)(236005)(8676002)(3660700001)(6506006)(2171002)(74316002)(189998001)(6306002)(6246003)(54896002)(53546003)(2900100001)(77096006)(68736007)(229853002)(9686003)(92566002)(53936002)(2501003)(5660300001)(2950100002)(7099028); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1601MB1314; 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 22:29:30.2119 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b0d01693-bd9f-4234-9888-57e53b52d8ed X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1601MB1314 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 22:29:34 -0000 Gotcha, thanks. 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 4:59:23 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, 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 This email is subject to important notices and disclaimers regarding legal = privilege, confidentiality, viruses and monitoring, available at www.iextra= ding.com/electroniccommunications