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

[Doohwan Lee]

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