From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0101.outbound.protection.outlook.com [104.47.34.101]) by dpdk.org (Postfix) with ESMTP id 205E71B05 for ; Thu, 16 Aug 2018 19:23:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IRfdCWuQil0vY2uDwQ3pMNnzKvJ6ycwtEDPVua8hB9Q=; b=PFQO8qbuFg78mxMXPyWIxKniTd8JXwZQIm3ms5MAw1jHSTltYh+7SaokJxPzT1cbjoTI3W31rcXgMz8HwormUC6r0L8jtOGgWLCDkz6n7aIPTHzRJrOe/uBb+BzTk442lFEsI7y8FY2NMWnjRBxLoPsZpw1sDg0zFsdvdCm/HdE= Received: from CY4PR2101MB0866.namprd21.prod.outlook.com (52.132.101.161) by CY4PR2101MB0723.namprd21.prod.outlook.com (52.132.100.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1080.2; Thu, 16 Aug 2018 17:23:13 +0000 Received: from CY4PR2101MB0866.namprd21.prod.outlook.com ([fe80::5c7b:aa05:6912:385e]) by CY4PR2101MB0866.namprd21.prod.outlook.com ([fe80::5c7b:aa05:6912:385e%4]) with mapi id 15.20.1080.009; Thu, 16 Aug 2018 17:23:13 +0000 From: Petr Houska To: "users@dpdk.org" Thread-Topic: ACL library doesn't match reliably Thread-Index: AdQ04ws4YJYuxZ4CTWesaDpMTsZVWAAopn7Q Date: Thu, 16 Aug 2018 17:23:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=t-pehous@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-08-15T22:30:02.0586825Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:0:84d5:561d:2069:c26] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR2101MB0723; 6:GLTP4SeDOp9KuwTrTd8z8Yh/mfQ4rq7szxngZu2XP9leJqY/6BxUHpgkIqfvVE8bhU/xU1YwK2wEBxTQpXVrI6I/VTBQb4/d38Wpd3YgL7LApbNwwWyt5LjgLTwEZfrWdVqYYpPUn11mC1jwMgDFTK/suPHsKgehz4oHSQ8fxd4LEHjG7XPvxV5kQYCgNxWRs/cRb58HAPE8GgBGi5i9MY9Gh0rj+ts7xZc/9qFpA4ey4FFEVUIjZigbB5BXxLRMHTE86XacIFcb5hGKVe4bwed4zMD2/jJg2AA1V9WrGkwFZXdYKgAhFuE2BGB4g5tnq70kIps8AA1tYZIRaATTp1sfTAsQ6blmxLkVGEyIn+u/0sqzjQGIiKVDcQ+GmoqRaGlHcFTOLQn3n3VudpRa56cogHb5QV/bnYHxGaVhzWeuOtp/sFbVPOowWu+YYUO8JplRn+dJkX6b8wfHZflc/Q==; 5:7CZBidox+OH6ux3D8yRS6Mjrc0hLlqm8BYgtFSlc2yFKBYvlMCwrfMJd6aVD0/Trj0a4axVsVKaiUO9N6ES7IxhEdfZw+mWgFz3KnUL368D8odmtIxLmkmOm0zoaWmyQ+sprylEeJVOE6lGLWaXwCZIJWtXnNF+R2yKMvTn40mI=; 7:F1CWUUJbxs/EbmFqCDUOm3X3Xb+7OLlnyWzdgrlI0hScl5AgOvbthE4obj5TFcAjafUXoAvt73U+LACRrLJUGQ4pW+zTBbQ9UUSGEvGtO8aF4yCC0aVGEuyfeg65w++fkWmqJn2B3TBJZiBqK+gYRVGcqXZdoq2PAbqyiaXV9QQOsR6lW/k+cz8E5c3PIWzbSsLLEf5BuukTvwM/nM3ZZsYtceKHNWPxgG4BQc3id/hsKzcItMOfkmo5aCBOju+M x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: dedb77a0-4c4b-43c9-4777-08d6039cf27b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(5600074)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7193020); SRVR:CY4PR2101MB0723; x-ms-traffictypediagnostic: CY4PR2101MB0723: authentication-results: spf=none (sender IP is ) smtp.mailfrom=t-pehous@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(20180801012)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231336)(8210008)(944501410)(52105095)(2018427008)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699016); SRVR:CY4PR2101MB0723; BCL:0; PCL:0; RULEID:; SRVR:CY4PR2101MB0723; x-forefront-prvs: 07665BE9D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(136003)(376002)(39860400002)(366004)(189003)(199004)(14454004)(256004)(14444005)(6916009)(7696005)(186003)(106356001)(55016002)(97736004)(8936002)(2501003)(68736007)(10290500003)(8990500004)(476003)(53546011)(6506007)(76176011)(486006)(2906002)(9686003)(478600001)(105586002)(25786009)(5640700003)(5660300001)(2351001)(54896002)(6306002)(4743002)(33656002)(53936002)(86362001)(81166006)(7736002)(6436002)(446003)(74316002)(10090500001)(9326002)(22452003)(316002)(6246003)(102836004)(8676002)(81156014)(2900100001)(5630700001)(99286004)(86612001)(5250100002)(11346002)(6116002)(790700001)(229853002)(1730700003)(46003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR2101MB0723; H:CY4PR2101MB0866.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: gTbGJsnoTReIQzsb5448a+cr2qpzdI7D8JuqHYZXqnOk+SqjrWIlliwdrDxOjPLKMQsKlZhar65PQAj7TKVJIbBDKqmdLXX3Y9MfWxmgZB6A9ENxCkfe5UlaPugcJjiGMenmIqhfqgYx7MfPKIe+53qgMHqHemmzQU13OaMVigs28Pqf4SWZpJ6t9hBvvy5HAc2Zj1DKnETBcLii2IuU6KFiKF9lxs4JnovV44Z3Ksldb7utIgDmPIEXOKVlDbGMD7v2EKO1wcXgjH6fyV24Vn3lQwXjgXeFK5p4I7wiUyU+BRB5BzTuLsf4m4YvnRWgjp6n4ejnq8BBZeOnx3cBatnc3+jMpbLtYccLuvzK9Lo= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: dedb77a0-4c4b-43c9-4777-08d6039cf27b X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2018 17:23:13.5639 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR2101MB0723 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] ACL library doesn't match reliably 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: Thu, 16 Aug 2018 17:23:17 -0000 Hi, I managed to find the source of the weird issues described in my previous e= mail (though the issues from bug #79 still persist), I still have few questions,= however. The problem lied in the order of fields definition in the `ipv4_defs` array= . The order has to correspond with `field_index` (which it didn't in my case and I complete= ly missed that). Maybe a validation that this precondition is true could be beneficial on rt= e_acl_build? That said I have few questions about the ACL library assumptions. The docum= entations states ` First field in the rule definition has to be one byte long. ` and ` All s= ubsequent fields has to be grouped into sets of 4 consecutive bytes. `. Going through the (matching) implementation it seemed to me that not only t= he first field in the rule definition has to be one byte long but that it also needs to correspond to = the field that is first in the input buffer. If that's the case it raises another question. Do the rule's fields have to= be (defined) in the order of their respective positions in input buffer? I.e. the first field in the = definition must correspond to lowest offset, the last to the highest, etc.? >>From my limited testing the matching seem to work even if it's not the case= . The matching Implementation, however, seems to hint (especially with the first 8bit fiel= d) that it wouldn't have to. From: Petr Houska Sent: Wednesday, August 15, 2018 3:30 PM To: 'users@dpdk.org' Subject: ACL library doesn't match reliably Hi, I've been trying to create a DPDK app that uses the ACL library and came ac= ross a really weird behavior. First I thought it has to be a bug in the ACL library (see bug #79) but whe= n I poked the library a bit more I found that the matching is extremely unreliable even when having _way_ smal= ler rulesets. Thus I'm more inclined to believe the problem lies in the way I use the library and not i= n the library itself. I have a structure that I match on, basically a 5tuple: ``` struct fiveTuple { uint8_t transportProtocol; uint16_t sourcePort; uint16_t destinationPort; uint32_t smth; IPAddress source; IPAddress destination; } __rte_cache_aligned; union ipAddress { uint32_t ipv4Address; uint8_t ipv6Address[16]; }; ``` Then I have a rule defined in following way: ``` /* Field's indexes in rules */ enum { ACL_RULE_IPV4_PROTO_FIELD, ACL_RULE_IPV4_SRC_FIELD, ACL_RULE_IPV4_FIELDS_NB }; /* Indexes of 4-byte chunks in input */ enum { ACL_RULE_IPV4_PROTO_CHUNK, ACL_RULE_IPV4_PORTS_CHUNK, ACL_RULE_IPV4_SRC_CHUNK, }; /* IPv4 rule definition */ struct rte_acl_field_def ipv4_defs[ACL_RULE_IPV4_FIELDS_NB] =3D { { .type =3D RTE_ACL_FIELD_TYPE_BITMASK, .size =3D sizeof(uint32_t), .field_index =3D ACL_RULE_IPV4_SRC_FIELD, .input_index =3D ACL_RULE_IPV4_SRC_CHUNK, .offset =3D offsetof(struct fiveTuple, source) + offsetof(union ipA= ddress, ipv4Address), }, { .type =3D RTE_ACL_FIELD_TYPE_MASK, .size =3D sizeof(uint8_t), .field_index =3D ACL_RULE_IPV4_PROTO_FIELD, .input_index =3D ACL_RULE_IPV4_PROTO_CHUNK, .offset =3D offsetof(struct fiveTuple, transportProtocol), }, }; ``` And a function that creates these rules & adds them to context: ``` static inline void fillRule2(struct acl4_rule* rule) { rule->field[ACL_RULE_IPV4_SRC_FIELD].value.u32 =3D IPv4(1,33,65,123); rule->field[ACL_RULE_IPV4_SRC_FIELD].mask_range.u32 =3D 0; rule->field[ACL_RULE_IPV4_PROTO_FIELD].value.u8 =3D 17; rule->field[ACL_RULE_IPV4_PROTO_FIELD].mask_range.u8 =3D -1; rule->data.userdata =3D 15; rule->data.category_mask =3D -1; rule->data.priority =3D 2; } static inline void fillRule1(struct acl4_rule* rule) { rule->field[ACL_RULE_IPV4_SRC_FIELD].value.u32 =3D IPv4(0,0,0,0); rule->field[ACL_RULE_IPV4_SRC_FIELD].mask_range.u32 =3D 0; rule->field[ACL_RULE_IPV4_PROTO_FIELD].value.u8 =3D 0; rule->field[ACL_RULE_IPV4_PROTO_FIELD].mask_range.u8 =3D 0; rule->data.userdata =3D 25; rule->data.category_mask =3D -1; rule->data.priority =3D 1; } ``` Then I create and build an ACL context with these rules. No errors are show= n, it's dump shows two rules with appropriate size and everything. The problem is with matching. When I send in data that should be matched by= both rules, i.e. the one with higher priority should get returned, the second one (rule1) gets returned even though it has lower priority. And what's even weirder when I change rule2 in a way so it's the _same_ as = rule1, rule1 stops matching and there're no matches reported. Matching code: ``` rte_acl_dump(aclCtx); printf("ACL for %hhu %u \n", *(ptrToFiveTuple + offsetof(struct fiveTuple, transportProtocol)), rte_be_to_cpu_32(*(uint32_t*)(ptrToFiveTuple + offsetof(struct fiveT= uple, source)) + offsetof(union ipAddress, ipv4Address))); if (unlikely(rte_acl_classify(aclCtx, (const uint8_t**)(&ptrToFiveTuple= ), &result, 1, 1) !=3D 0)) { RTE_LOG(ERR, NATD, "Failed to classify a packet,\n"); return -EINVAL; } printf("____RESULT: %u\n", result); ``` Log for the rules as they're defined above: ``` acl context @0x7f1a0019c8c0 socket_id=3D0 alg=3D1 max_rules=3D10000 rule_size=3D48 num_rules=3D2 num_categories=3D1 num_tries=3D1 ACL for 17 18956667 //18956667 is IP: 1.33.65.123 ____RESULT: 25 ``` Log for the situation when rule2 is changed so that it's the same as rule1: ``` { rule->field[ACL_RULE_IPV4_SRC_FIELD].value.u32 =3D IPv4(0,0,0,0); rule->field[ACL_RULE_IPV4_SRC_FIELD].mask_range.u32 =3D 0; rule->field[ACL_RULE_IPV4_PROTO_FIELD].value.u8 =3D 0; rule->field[ACL_RULE_IPV4_PROTO_FIELD].mask_range.u8 =3D 0; rule->data.userdata =3D 15; rule->data.category_mask =3D -1; rule->data.priority =3D 2; } ``` ``` acl context @0x7f1a0019c8c0 socket_id=3D0 alg=3D1 max_rules=3D10000 rule_size=3D48 num_rules=3D2 num_categories=3D1 num_tries=3D1 ACL for 17 18956667 //18956667 is IP: 1.33.65.123 ____RESULT: 0 ``` To be perfectly honest I have literally no idea what am I doing wrong or wh= ere the problem might lie. Any help would be greatly appreciated. Petr Houska Azure Intern