IPv4(1,2,3,4) means 0x01020304, and it is already host order (little endian). It need not to be converted using rte_be_to_cpu32() for setting rule.
2017-06-22 15:27 GMT+09:00 Shyam Shrivastav <shrivastav.sh...@gmail.com>: > > Yes Doohwan, it is there in rte_ip.h just saw. So this conversion leaves > the address in big endian format. Theoretically, we are supposed to add the > acl fields in host order, if you see pipeline code even for ip address with > mask, following conversion is being done line 1096 > examples/ip_pipeline/pipeline-firewall.c > > key.type = PIPELINE_FIREWALL_IPV4_5TUPLE; > key.key.ipv4_5tuple.src_ip = rte_be_to_cpu_32(sipaddr.s_addr); > key.key.ipv4_5tuple.src_ip_mask = sipdepth; > key.key.ipv4_5tuple.dst_ip = rte_be_to_cpu_32(dipaddr.s_addr); > > I would suggest this in your code > > rule->field[2].value.u32 = rte_be_to_cpu_32(IPv4(1,2,3,4)); > rule->filed[2].mask_range.u32 = rte_be_to_cpu_32(IPv4(1,10,10,10)); > > > > > > > On Thu, Jun 22, 2017 at 11:28 AM, Doohwan Lee <let...@gmail.com> wrote: > >> Ok. The code to set rule for IPv4 address is like below. >> >> ------------------------------------------------------------ >> #define IPv4(a,b,c,d) ((uint32_t)(((a) & 0xff) << 24) | \ >> (((b) & 0xff) << 16) | \ >> (((c) & 0xff) << 8) | \ >> ((d) & 0xff)) >> >> ....... >> rule->field[2].value.u32 = IPv4(1,2,3,4); >> rule->filed[2].mask_range.u32 = IPv4(1,10,10,10); >> ....... >> ------------------------------------------------------------- >> >> The macro IPv4() is from the DPDK (rte_ip.h) >> The matching data is from the packet. so it is network order. (big endian) >> >> >> >> On Thu, Jun 22, 2017 at 1:26 PM, Shyam Shrivastav < >> shrivastav.sh...@gmail.com> wrote: >> >>> Yes if these are the results then might be some issue, but can not be >>> sure unless do this myself, have been using ACL library but not this case >>> till now. >>> Can you share code fragment converting dotted decimal to integer if >>> possible .. >>> >>> On Thu, Jun 22, 2017 at 7:57 AM, Doohwan Lee <let...@gmail.com> wrote: >>> >>>> Thank you Shyam. >>>> Let me explain my situation in detail. >>>> All the cases described below use RTE_ACL_FIELD_TYPE_RANGE type. >>>> >>>> ----------------------------------------------- >>>> Case 1. >>>> rule: 1.2.3.4 ~ 1.2.3.4 >>>> packet: 1.2.3.4 >>>> result: match (correct) >>>> >>>> Case 2. >>>> rule: 1.2.3.4 ~ 1.10.10.10 >>>> packet: 1.2.10.5 >>>> result: match (correct) >>>> >>>> Case 3 >>>> rule: 1.2.3.4 ~ 1.10.10.10 >>>> packet: 1.10.10.11 >>>> result: not match (correct) >>>> >>>> Case 4 >>>> rule: 1.2.3.4 ~ 1.10.10.10 >>>> packet: 1.2.3.10 >>>> result: match (correct) >>>> >>>> Case 5: >>>> rule: 1.2.3.4~1.10.10.10 >>>> packet: 1.2.10.11 >>>> result: not match (incorrect) >>>> >>>> Case 6: >>>> rule: 1.2.3.4~1.10.10.10 >>>> packet: 1.2.10.3 >>>> result: not match (incorrect) >>>> ----------------------------------------------- >>>> >>>> >>>> Considering case 1~4, It shows expected results and there is no problem >>>> with byte ordering. >>>> But, in case 5~6, the result should be 'match' but it was not. >>>> This is why I doubt DPDK ACL library doesn't support 32-bit range >>>> matching. >>>> >>>> >>>> On Wed, Jun 21, 2017 at 9:09 PM, Shyam Shrivastav < >>>> shrivastav.sh...@gmail.com> wrote: >>>> >>>>> I haven't used range type with 32 bit integers yet ... >>>>> Just some theory in case if you haven't already taken into account, >>>>> if little-endian host 10.10.10.30 actually means 0x1e0a0a0a for acl match, >>>>> dotted decimal is in big endian so when in little endian host you need to >>>>> add it other way round as integers for matching. This means if you add >>>>> range 0x0a0a0a0a to 0x1e1e1e1e should match 10.10.10.30, this is my >>>>> understanding theoretically .. >>>>> >>>>> On Wed, Jun 21, 2017 at 4:54 PM, Doohwan Lee <let...@gmail.com> wrote: >>>>> >>>>>> Yes. you are right. I also already knew that 32bit match with mask >>>>>> type works well. >>>>>> My point is 32bit match with 'range type' doesn't work in some case. >>>>>> >>>>>> >>>>>> On Wed, Jun 21, 2017 at 6:46 PM, Anupam Kapoor < >>>>>> anupam.kap...@gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> On Wed, Jun 21, 2017 at 11:36 AM, Doohwan Lee <let...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> DPDK ACL library uses multi-bit trie with 8-bit stride. >>>>>>>> I guess that implementation of the trie doesn't support 32bit range >>>>>>>> matching. >>>>>>>> >>>>>>> >>>>>>> well, you _can_ have address wildcard matches e.g. an address+mask >>>>>>> combination of 1.2.3.0/24 would match all addresses 1.2.3.[0..255] >>>>>>> >>>>>>> -- >>>>>>> kind regards >>>>>>> anupam >>>>>>> >>>>>>> In the beginning was the lambda, and the lambda was with Emacs, and >>>>>>> Emacs was the lambda. >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >