* [dpdk-dev] ACL: BUG: rte_acl_classify_scalar mismatch when use a special rule @ 2016-07-27 10:34 =?gb18030?B?za+9+A==?= 2016-07-27 11:31 ` Ananyev, Konstantin 0 siblings, 1 reply; 3+ messages in thread From: =?gb18030?B?za+9+A==?= @ 2016-07-27 10:34 UTC (permalink / raw) To: =?gb18030?B?ZGV2?= [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="gb18030", Size: 3588 bytes --] define a rule as following: struct acl_ipv4_rule acl_rule[] = { { .data = {.userdata = 103, .category_mask = 1, .priority = 1}, /* proto */ .field[0] = {.value.u8 = 0, .mask_range.u8 = 0x0,}, /* source IPv4 */ .field[1] = {.value.u32 = IPv4(0, 0, 0, 0), .mask_range.u32 = 0,}, /* destination IPv4 */ .field[2] = {.value.u32 = IPv4(192, 168, 2, 4), .mask_range.u32 = 32,}, /* source port */ .field[3] = {.value.u16 = 0, .mask_range.u16 = 0xffff,}, /* destination port */ .field[4] = {.value.u16 = 1024, .mask_range.u16 = 0xffff,}, }, }; build a pkt like this: pv4_hdr->next_proto_id = 6; ipv4_hdr->src_addr = rte_cpu_to_be_32(IPv4(10, 18, 2, 3)); ipv4_hdr->dst_addr = rte_cpu_to_be_32(IPv4(192, 168, 2, 4)); port = (uint16_t*)((unsigned char*)ipv4_hdr + sizeof(struct ipv4_hdr)); port[0] = rte_cpu_to_be_16(3333); port[1] = rte_cpu_to_be_16(4608); rte_acl_classify_scalar will mismatch this packet! i readed rte_acl_classify_scalar function, and found the reason: while (flows.started > 0) { input0 = GET_NEXT_4BYTES(parms, 0); input1 = GET_NEXT_4BYTES(parms, 1); for (n = 0; n < 4; n++) { transition0 = scalar_transition(flows.trans, transition0, (uint8_t)input0); input0 >>= CHAR_BIT; transition1 = scalar_transition(flows.trans, transition1, (uint8_t)input1); input1 >>= CHAR_BIT; } while ((transition0 | transition1) & RTE_ACL_NODE_MATCH) { transition0 = acl_match_check(transition0, 0, ctx, parms, &flows, resolve_priority_scalar); transition1 = acl_match_check(transition1, 1, ctx, parms, &flows, resolve_priority_scalar); } } everytime, scalar get 4bytes to transition, and usually it work well, but if we set a acl rule as prior, mismatch will appear. this is because field[3] is a 100% wild node, so it was removed as a deactivated field. in this situation, when rte_acl_classify_scalar runs, proto/sip/dip match ok, and then it skip sport because it was removed. now input0 is a int value(4 bytes) started form dport. it will get a match-node after 2 bytes match(dport is a short value), but cycle stoped untill n = 4, finally it translated to another node which is not a match-node, the mismatch happened. i'm not sure search_sse_8/search_sse_4/search_avx2x16 is Ok. how to fix it? i think set GET_NEXT_4BYTES to GET_NEXT_BYTE will solve this problem, but it will influence performance. another way, don't use acl_rule_stats to remove deactivated field, but code will change a lot. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dpdk-dev] ACL: BUG: rte_acl_classify_scalar mismatch when use a special rule 2016-07-27 10:34 [dpdk-dev] ACL: BUG: rte_acl_classify_scalar mismatch when use a special rule =?gb18030?B?za+9+A==?= @ 2016-07-27 11:31 ` Ananyev, Konstantin 2016-07-27 14:12 ` [dpdk-dev] =?gb18030?q?ACL=3A_BUG=3A_rte=5Facl=5Fclassify=5Fscalar_mismatch_when_usea=09special_rule?= =?gb18030?B?za+9+A==?= 0 siblings, 1 reply; 3+ messages in thread From: Ananyev, Konstantin @ 2016-07-27 11:31 UTC (permalink / raw) To: tongjinam, dev Hi, > > define a rule as following: > > struct acl_ipv4_rule acl_rule[] = { > { > .data = {.userdata = 103, .category_mask = 1, .priority = 1}, > /* proto */ > .field[0] = {.value.u8 = 0, .mask_range.u8 = 0x0,}, > /* source IPv4 */ > .field[1] = {.value.u32 = IPv4(0, 0, 0, 0), .mask_range.u32 = 0,}, > /* destination IPv4 */ > .field[2] = {.value.u32 = IPv4(192, 168, 2, 4), .mask_range.u32 = 32,}, > /* source port */ > .field[3] = {.value.u16 = 0, .mask_range.u16 = 0xffff,}, > /* destination port */ > .field[4] = {.value.u16 = 1024, .mask_range.u16 = 0xffff,}, > }, > }; > > build a pkt like this: > > pv4_hdr->next_proto_id = 6; > ipv4_hdr->src_addr = rte_cpu_to_be_32(IPv4(10, 18, 2, 3)); > ipv4_hdr->dst_addr = rte_cpu_to_be_32(IPv4(192, 168, 2, 4)); > port = (uint16_t*)((unsigned char*)ipv4_hdr + sizeof(struct ipv4_hdr)); > port[0] = rte_cpu_to_be_16(3333); > port[1] = rte_cpu_to_be_16(4608); > > rte_acl_classify_scalar will mismatch this packet! > > i readed rte_acl_classify_scalar function, and found the reason: > > while (flows.started > 0) { > > input0 = GET_NEXT_4BYTES(parms, 0); > input1 = GET_NEXT_4BYTES(parms, 1); > > for (n = 0; n < 4; n++) { > > transition0 = scalar_transition(flows.trans, > transition0, (uint8_t)input0); > input0 >>= CHAR_BIT; > > transition1 = scalar_transition(flows.trans, > transition1, (uint8_t)input1); > input1 >>= CHAR_BIT; > } > > while ((transition0 | transition1) & RTE_ACL_NODE_MATCH) { > transition0 = acl_match_check(transition0, > 0, ctx, parms, &flows, resolve_priority_scalar); > transition1 = acl_match_check(transition1, > 1, ctx, parms, &flows, resolve_priority_scalar); > } > } > > everytime, scalar get 4bytes to transition, and usually it work well, but if we set a acl rule as prior, mismatch will appear. > this is because field[3] is a 100% wild node, so it was removed as a deactivated field. > > in this situation, when rte_acl_classify_scalar runs, proto/sip/dip match ok, and then it skip sport because it was removed. > now input0 is a int value(4 bytes) started form dport. > it will get a match-node after 2 bytes match(dport is a short value), but cycle stoped untill n = 4, finally it translated to another node which is > not a match-node, the mismatch happened. > > i'm not sure search_sse_8/search_sse_4/search_avx2x16 is Ok. > > how to fix it? > i think set GET_NEXT_4BYTES to GET_NEXT_BYTE will solve this problem, but it will influence performance. > another way, don't use acl_rule_stats to remove deactivated field, but code will change a lot. If you believe there is a problem, could you try to reproduce it with app/testacl, and provide a rule file and a trace file? Thanks Konstantin ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dpdk-dev] =?gb18030?q?ACL=3A_BUG=3A_rte=5Facl=5Fclassify=5Fscalar_mismatch_when_usea=09special_rule?= 2016-07-27 11:31 ` Ananyev, Konstantin @ 2016-07-27 14:12 ` =?gb18030?B?za+9+A==?= 0 siblings, 0 replies; 3+ messages in thread From: =?gb18030?B?za+9+A==?= @ 2016-07-27 14:12 UTC (permalink / raw) To: =?gb18030?B?QW5hbnlldiwgS29uc3RhbnRpbg==?=, =?gb18030?B?ZGV2?= [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="gb18030", Size: 5105 bytes --] sorry, i make a mistake when set the rte_acl_field_def. the input_index is not consecutive when define sport/dport like this: { .type = RTE_ACL_FIELD_TYPE_RANGE, .size = sizeof(uint16_t), .field_index = SRCP_FIELD_IPV4, .input_index = RTE_ACL_IPV4_SPORT, .offset = sizeof(struct ipv4_hdr) - offsetof(struct ipv4_hdr, next_proto_id), }, { .type = RTE_ACL_FIELD_TYPE_RANGE, .size = sizeof(uint16_t), .field_index = DSTP_FIELD_IPV4, .input_index = RTE_ACL_IPV4_DPORT, .offset = sizeof(struct ipv4_hdr) - offsetof(struct ipv4_hdr, next_proto_id) + sizeof(uint16_t), }, input_index RTE_ACL_IPV4_SPORT is not equal to RTE_ACL_IPV4_DPORT, and size is uint16_t not 4 consecutive bytes. in program guide, it has a instruction as following: [input_index As mentioned above, all input fields, except the very first one, must be in groups of 4 consecutive bytes. The input index specifies to which input group that field belongs to.] change rte_acl_field_def as following, then match ok: { .type = RTE_ACL_FIELD_TYPE_RANGE, .size = sizeof(uint16_t), .field_index = SRCP_FIELD_IPV4, .input_index = RTE_ACL_IPV4_PORT, .offset = sizeof(struct ipv4_hdr) - offsetof(struct ipv4_hdr, next_proto_id), }, { .type = RTE_ACL_FIELD_TYPE_RANGE, .size = sizeof(uint16_t), .field_index = DSTP_FIELD_IPV4, .input_index = RTE_ACL_IPV4_PORT, .offset = sizeof(struct ipv4_hdr) - offsetof(struct ipv4_hdr, next_proto_id) + sizeof(uint16_t), }, emr, read the code of ACL lib again, especially acl_calc_wildness and acl_rule_stats functions, full of trick! ------------------ Original ------------------ From: "Ananyev, Konstantin";<konstantin.ananyev@intel.com>; Send time: Wednesday, Jul 27, 2016 7:31 PM To: "ͯ½ø"<tongjinam@qq.com>; "dev"<dev@dpdk.org>; Subject: RE: [dpdk-dev] ACL: BUG: rte_acl_classify_scalar mismatch when usea special rule Hi, > > define a rule as following: > > struct acl_ipv4_rule acl_rule[] = { > { > .data = {.userdata = 103, .category_mask = 1, .priority = 1}, > /* proto */ > .field[0] = {.value.u8 = 0, .mask_range.u8 = 0x0,}, > /* source IPv4 */ > .field[1] = {.value.u32 = IPv4(0, 0, 0, 0), .mask_range.u32 = 0,}, > /* destination IPv4 */ > .field[2] = {.value.u32 = IPv4(192, 168, 2, 4), .mask_range.u32 = 32,}, > /* source port */ > .field[3] = {.value.u16 = 0, .mask_range.u16 = 0xffff,}, > /* destination port */ > .field[4] = {.value.u16 = 1024, .mask_range.u16 = 0xffff,}, > }, > }; > > build a pkt like this: > > pv4_hdr->next_proto_id = 6; > ipv4_hdr->src_addr = rte_cpu_to_be_32(IPv4(10, 18, 2, 3)); > ipv4_hdr->dst_addr = rte_cpu_to_be_32(IPv4(192, 168, 2, 4)); > port = (uint16_t*)((unsigned char*)ipv4_hdr + sizeof(struct ipv4_hdr)); > port[0] = rte_cpu_to_be_16(3333); > port[1] = rte_cpu_to_be_16(4608); > > rte_acl_classify_scalar will mismatch this packet! > > i readed rte_acl_classify_scalar function, and found the reason: > > while (flows.started > 0) { > > input0 = GET_NEXT_4BYTES(parms, 0); > input1 = GET_NEXT_4BYTES(parms, 1); > > for (n = 0; n < 4; n++) { > > transition0 = scalar_transition(flows.trans, > transition0, (uint8_t)input0); > input0 >>= CHAR_BIT; > > transition1 = scalar_transition(flows.trans, > transition1, (uint8_t)input1); > input1 >>= CHAR_BIT; > } > > while ((transition0 | transition1) & RTE_ACL_NODE_MATCH) { > transition0 = acl_match_check(transition0, > 0, ctx, parms, &flows, resolve_priority_scalar); > transition1 = acl_match_check(transition1, > 1, ctx, parms, &flows, resolve_priority_scalar); > } > } > > everytime, scalar get 4bytes to transition, and usually it work well, but if we set a acl rule as prior, mismatch will appear. > this is because field[3] is a 100% wild node, so it was removed as a deactivated field. > > in this situation, when rte_acl_classify_scalar runs, proto/sip/dip match ok, and then it skip sport because it was removed. > now input0 is a int value(4 bytes) started form dport. > it will get a match-node after 2 bytes match(dport is a short value), but cycle stoped untill n = 4, finally it translated to another node which is > not a match-node, the mismatch happened. > > i'm not sure search_sse_8/search_sse_4/search_avx2x16 is Ok. > > how to fix it? > i think set GET_NEXT_4BYTES to GET_NEXT_BYTE will solve this problem, but it will influence performance. > another way, don't use acl_rule_stats to remove deactivated field, but code will change a lot. If you believe there is a problem, could you try to reproduce it with app/testacl, and provide a rule file and a trace file? Thanks Konstantin ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-07-27 14:12 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-07-27 10:34 [dpdk-dev] ACL: BUG: rte_acl_classify_scalar mismatch when use a special rule =?gb18030?B?za+9+A==?= 2016-07-27 11:31 ` Ananyev, Konstantin 2016-07-27 14:12 ` [dpdk-dev] =?gb18030?q?ACL=3A_BUG=3A_rte=5Facl=5Fclassify=5Fscalar_mismatch_when_usea=09special_rule?= =?gb18030?B?za+9+A==?=
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).