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

[Shyam Shrivastav]

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
dev at dpdk.org

On Thu, Jun 22, 2017 at 12:57 PM, Doohwan Lee <letsme at 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.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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>