[dpdk-users] Question about range type of DPDK ACL

[Doohwan Lee]

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.shyam at 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 <letsme at 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.shyam at 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 <letsme at 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.shyam at 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 <letsme at 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.shyam at 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 <letsme at 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.kapoor at gmail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Jun 21, 2017 at 11:36 AM, Doohwan Lee <letsme at 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>