Yes you are right , the IPv4 conversion keeps the host byte and ip address in packet mbuf would appear other way round for matching. I got confused because firewall parser code reads the dotted decimal user input as big endian, that's why rte_be_to_cpu32 is required. Hope some help comes your way, you can also try posting in dpdk dev d...@dpdk.org
On Thu, Jun 22, 2017 at 12:57 PM, Doohwan Lee <let...@gmail.com> wrote: > I really appreciate your help. but I think there's some misunderstanding. > I also know that DPDK ACL rule expects host order. > > IPv4(1,2,3,4) means 0x01020304 and it is little endian(host order) again. > and the IP address 1.2.3.4 in packet data on memory is 0x04030201 (big > endian). > So, I think I didn't have any mistake for using DPDK ACL library. > > > > 2017-06-22 16:12 GMT+09:00 Shyam Shrivastav <shrivastav.sh...@gmail.com>: > >> No it is not as dotted decimal representation is in big endian that is as >> they appear in packet, but acl library expects addition in host byte order. >> I would suggest to try the change, in firewall also we are converting user >> input in dotted decimal to integer then to host byte order .., anyway it is >> your choice >> >> On Thu, Jun 22, 2017 at 12:28 PM, Doohwan Lee <let...@gmail.com> wrote: >> >>> 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. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >