Thank you for your opinion. But I already checked byte ordering. It is used correctly like you mentioned. And, ACL library works good except 32bit matching with range type.
DPDK ACL library uses multi-bit trie with 8-bit stride. I guess that implementation of the trie doesn't support 32bit range matching. On Wed, Jun 21, 2017 at 2:11 PM, Shyam Shrivastav < shrivastav.sh...@gmail.com> wrote: > Yes it can be but generally not used. Check dotted decimal IP address to > integer conversion, ACL library expects host byte order while adding acl > rules and network byte order while matching .. > > FROM ADD > > rules : Array of rules to add to the ACL context. Note that all fields > in rte_acl_rule structures are expected to be in host byte order. Each rule > expected to be in the same format and not exceed size specified at ACL > context creation time. > > FROM CLASSIFY > > data : Array of pointers to input data buffers to perform search. > Note that all fields in input data buffers supposed to be in network byte > order (MSB). > > > On Wed, Jun 21, 2017 at 6:20 AM, 이두환 <let...@gmail.com> wrote: > >> IPv4 address can be just 4byte integer value. >> 10.10.10.10 means 0x0a0a0a0a and 20.20.20.20 means 0x14141414 >> 10.10.10.30 is 0x0a0a0a1e and it is greater than 0x0a0a0a0a and less then >> 0x14141414. >> So, I think it should be matched but the result was not. >> Did I miss something? >> >> On Tue, Jun 20, 2017 at 5:58 PM, Shyam Shrivastav < >> shrivastav.sh...@gmail.com> wrote: >> >>> RTE_ACL_FIELD_TYPE_RANGE is for linear integer range like port numbers >>> For ip addresses RTE_ACL_FIELD_TYPE_MASK should be used. >>> >>> On Tue, Jun 20, 2017 at 1:57 PM, 이두환 <let...@gmail.com> wrote: >>> >>>> Hello everyone. >>>> >>>> I want to implement some feature like ACL using DPDK ACL library. >>>> so, I defined rule like below. >>>> >>>> struct acl_match_component >>>> { >>>> uint8_t protocol; >>>> uint32_t sip; >>>> uint32_t dip; >>>> uint16_t sport; >>>> uint16_t dport; >>>> uint16_t in_if; >>>> uint16_t out_if; >>>> } >>>> >>>> >>>> struct rte_acl_field_def ipv4_defs[7] = { >>>> { >>>> .type = RTE_ACL_FIELD_TYPE_RANGE, >>>> .size = sizeof(uint8_t), >>>> .field_index = 0, >>>> .input_index = 0, >>>> .offset = 0 >>>> }, >>>> { >>>> .type = RTE_ACL_FIELD_TYPE_RANGE, >>>> .size = sizeof(uint32_t), >>>> .field_index = 1, >>>> .input_index = 1, >>>> .offset = offsetof(struct acl_match_component, sip) >>>> }, >>>> { >>>> .type = RTE_ACL_FIELD_TYPE_RANGE, >>>> .size = sizeof(uint32_t), >>>> .field_index = 2, >>>> .input_index = 2, >>>> .offset = offsetof(struct acl_match_component, dip) >>>> }, >>>> { >>>> .type = RTE_ACL_FIELD_TYPE_RANGE, >>>> .size = sizeof(uint16_t), >>>> .field_index = 3, >>>> .input_index = 3, >>>> .offset = offsetof(struct acl_match_component, sport) >>>> }, >>>> { >>>> .type = RTE_ACL_FIELD_TYPE_RANGE, >>>> .size = sizeof(uint16_t), >>>> .field_index = 4, >>>> .input_index = 3, >>>> .offset = offsetof(struct acl_match_component, dport) >>>> }, >>>> { >>>> .type = RTE_ACL_FIELD_TYPE_RANGE, >>>> .size = sizeof(uint16_t), >>>> .field_index = 5, >>>> .input_index = 4, >>>> .offset = offsetof(struct acl_match_component, in_if) >>>> }, >>>> { >>>> .type = RTE_ACL_FIELD_TYPE_RANGE, >>>> .size = sizeof(uint16_t), >>>> .field_index = 6, >>>> .input_index = 4, >>>> .offset = offsetof(struct acl_match_component, out_if) >>>> }, >>>> }; >>>> >>>> I defined 32bit IPv4 address filed as RTE_ACL_FIELD_TYPE_RANGE type. >>>> and I set rte_acl_field for IP field like below. >>>> >>>> value.u32 = IPv4(10,10,10,10); >>>> mask_range.u32 = IPv4(20,20,20,20); >>>> >>>> In this case, I think IP 10.10.10.15 and 10.10.10.30 should be matched. >>>> but result was IP 10.10.10.15 was matched and 10.10.10.30 was not >>>> matched. >>>> >>>> I am using DPDK 16.04 and there was no example in the DPDK source using >>>> 32bit field as range type. >>>> Range type with 16bit field (ex. port number) works well. >>>> And, DPDK 17.05 has no meaningful changes on ACL library compare to DPDK >>>> 16.04 >>>> >>>> Do you have any idea about this? >>>> >>>> Thank you. >>>> >>> >>> >> >