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

[Doohwan Lee]

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.
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>