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

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

[이두환]

Hello everyone.

I want to implement some feature like ACL using DPDK ACL library.
so, I defined rule like below.

struct acl_match_component
{
    uint8_t protocol;
    uint32_t sip;
    uint32_t dip;
    uint16_t sport;
    uint16_t dport;
    uint16_t in_if;
    uint16_t out_if;
}


struct rte_acl_field_def ipv4_defs[7] = {
    {
        .type = RTE_ACL_FIELD_TYPE_RANGE,
        .size = sizeof(uint8_t),
        .field_index = 0,
        .input_index = 0,
        .offset = 0
    },
    {
        .type = RTE_ACL_FIELD_TYPE_RANGE,
        .size = sizeof(uint32_t),
        .field_index = 1,
        .input_index = 1,
        .offset = offsetof(struct acl_match_component, sip)
    },
    {
        .type = RTE_ACL_FIELD_TYPE_RANGE,
        .size = sizeof(uint32_t),
        .field_index = 2,
        .input_index = 2,
        .offset = offsetof(struct acl_match_component, dip)
    },
    {
        .type = RTE_ACL_FIELD_TYPE_RANGE,
        .size = sizeof(uint16_t),
        .field_index = 3,
        .input_index = 3,
        .offset = offsetof(struct acl_match_component, sport)
    },
    {
        .type = RTE_ACL_FIELD_TYPE_RANGE,
        .size = sizeof(uint16_t),
        .field_index = 4,
        .input_index = 3,
        .offset = offsetof(struct acl_match_component, dport)
    },
    {
        .type = RTE_ACL_FIELD_TYPE_RANGE,
        .size = sizeof(uint16_t),
        .field_index = 5,
        .input_index = 4,
        .offset = offsetof(struct acl_match_component, in_if)
    },
    {
        .type = RTE_ACL_FIELD_TYPE_RANGE,
        .size = sizeof(uint16_t),
        .field_index = 6,
        .input_index = 4,
        .offset = offsetof(struct acl_match_component, out_if)
    },
};

I defined 32bit IPv4 address filed as RTE_ACL_FIELD_TYPE_RANGE type.
and I set rte_acl_field for IP field like below.

value.u32 = IPv4(10,10,10,10);
mask_range.u32 = IPv4(20,20,20,20);

In this case, I think IP 10.10.10.15 and 10.10.10.30 should be matched.
but result was IP 10.10.10.15 was matched and 10.10.10.30 was not matched.

I am using DPDK 16.04 and there was no example in the DPDK source using
32bit field as range type.
Range type with 16bit field (ex. port number) works well.
And, DPDK 17.05 has no meaningful changes on ACL library compare to DPDK
16.04

Do you have any idea about this?

Thank you.

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

[Shyam Shrivastav]

RTE_ACL_FIELD_TYPE_RANGE is for linear integer range like port numbers
For ip addresses RTE_ACL_FIELD_TYPE_MASK should be used.

On Tue, Jun 20, 2017 at 1:57 PM, 이두환 <letsme@gmail.com> wrote:

> Hello everyone.
>
> I want to implement some feature like ACL using DPDK ACL library.
> so, I defined rule like below.
>
> struct acl_match_component
> {
>     uint8_t protocol;
>     uint32_t sip;
>     uint32_t dip;
>     uint16_t sport;
>     uint16_t dport;
>     uint16_t in_if;
>     uint16_t out_if;
> }
>
>
> struct rte_acl_field_def ipv4_defs[7] = {
>     {
>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>         .size = sizeof(uint8_t),
>         .field_index = 0,
>         .input_index = 0,
>         .offset = 0
>     },
>     {
>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>         .size = sizeof(uint32_t),
>         .field_index = 1,
>         .input_index = 1,
>         .offset = offsetof(struct acl_match_component, sip)
>     },
>     {
>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>         .size = sizeof(uint32_t),
>         .field_index = 2,
>         .input_index = 2,
>         .offset = offsetof(struct acl_match_component, dip)
>     },
>     {
>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>         .size = sizeof(uint16_t),
>         .field_index = 3,
>         .input_index = 3,
>         .offset = offsetof(struct acl_match_component, sport)
>     },
>     {
>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>         .size = sizeof(uint16_t),
>         .field_index = 4,
>         .input_index = 3,
>         .offset = offsetof(struct acl_match_component, dport)
>     },
>     {
>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>         .size = sizeof(uint16_t),
>         .field_index = 5,
>         .input_index = 4,
>         .offset = offsetof(struct acl_match_component, in_if)
>     },
>     {
>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>         .size = sizeof(uint16_t),
>         .field_index = 6,
>         .input_index = 4,
>         .offset = offsetof(struct acl_match_component, out_if)
>     },
> };
>
> I defined 32bit IPv4 address filed as RTE_ACL_FIELD_TYPE_RANGE type.
> and I set rte_acl_field for IP field like below.
>
> value.u32 = IPv4(10,10,10,10);
> mask_range.u32 = IPv4(20,20,20,20);
>
> In this case, I think IP 10.10.10.15 and 10.10.10.30 should be matched.
> but result was IP 10.10.10.15 was matched and 10.10.10.30 was not matched.
>
> I am using DPDK 16.04 and there was no example in the DPDK source using
> 32bit field as range type.
> Range type with 16bit field (ex. port number) works well.
> And, DPDK 17.05 has no meaningful changes on ACL library compare to DPDK
> 16.04
>
> Do you have any idea about this?
>
> Thank you.
>

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

[이두환]

IPv4 address can be just 4byte integer value.
10.10.10.10 means 0x0a0a0a0a and 20.20.20.20 means 0x14141414
10.10.10.30 is 0x0a0a0a1e and it is greater than 0x0a0a0a0a and less then
0x14141414.
So, I think it should be matched but the result was not.
Did I miss something?

On Tue, Jun 20, 2017 at 5:58 PM, Shyam Shrivastav <
shrivastav.shyam@gmail.com> wrote:

> RTE_ACL_FIELD_TYPE_RANGE is for linear integer range like port numbers
> For ip addresses RTE_ACL_FIELD_TYPE_MASK should be used.
>
> On Tue, Jun 20, 2017 at 1:57 PM, 이두환 <letsme@gmail.com> wrote:
>
>> Hello everyone.
>>
>> I want to implement some feature like ACL using DPDK ACL library.
>> so, I defined rule like below.
>>
>> struct acl_match_component
>> {
>>     uint8_t protocol;
>>     uint32_t sip;
>>     uint32_t dip;
>>     uint16_t sport;
>>     uint16_t dport;
>>     uint16_t in_if;
>>     uint16_t out_if;
>> }
>>
>>
>> struct rte_acl_field_def ipv4_defs[7] = {
>>     {
>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>         .size = sizeof(uint8_t),
>>         .field_index = 0,
>>         .input_index = 0,
>>         .offset = 0
>>     },
>>     {
>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>         .size = sizeof(uint32_t),
>>         .field_index = 1,
>>         .input_index = 1,
>>         .offset = offsetof(struct acl_match_component, sip)
>>     },
>>     {
>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>         .size = sizeof(uint32_t),
>>         .field_index = 2,
>>         .input_index = 2,
>>         .offset = offsetof(struct acl_match_component, dip)
>>     },
>>     {
>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>         .size = sizeof(uint16_t),
>>         .field_index = 3,
>>         .input_index = 3,
>>         .offset = offsetof(struct acl_match_component, sport)
>>     },
>>     {
>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>         .size = sizeof(uint16_t),
>>         .field_index = 4,
>>         .input_index = 3,
>>         .offset = offsetof(struct acl_match_component, dport)
>>     },
>>     {
>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>         .size = sizeof(uint16_t),
>>         .field_index = 5,
>>         .input_index = 4,
>>         .offset = offsetof(struct acl_match_component, in_if)
>>     },
>>     {
>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>         .size = sizeof(uint16_t),
>>         .field_index = 6,
>>         .input_index = 4,
>>         .offset = offsetof(struct acl_match_component, out_if)
>>     },
>> };
>>
>> I defined 32bit IPv4 address filed as RTE_ACL_FIELD_TYPE_RANGE type.
>> and I set rte_acl_field for IP field like below.
>>
>> value.u32 = IPv4(10,10,10,10);
>> mask_range.u32 = IPv4(20,20,20,20);
>>
>> In this case, I think IP 10.10.10.15 and 10.10.10.30 should be matched.
>> but result was IP 10.10.10.15 was matched and 10.10.10.30 was not matched.
>>
>> I am using DPDK 16.04 and there was no example in the DPDK source using
>> 32bit field as range type.
>> Range type with 16bit field (ex. port number) works well.
>> And, DPDK 17.05 has no meaningful changes on ACL library compare to DPDK
>> 16.04
>>
>> Do you have any idea about this?
>>
>> Thank you.
>>
>
>

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

[Shyam Shrivastav]

Yes it can be but generally not used. Check dotted decimal IP address to
integer conversion, ACL library expects host byte order while adding acl
rules and network byte order while matching ..

FROM ADD

rules    : Array of rules to add to the ACL context. Note that all fields
in rte_acl_rule structures are expected to be in host byte order. Each rule
expected to be in the same format and not exceed size specified at ACL
context creation time.

FROM CLASSIFY

data      : Array of pointers to input data buffers to perform search. Note
that all fields in input data buffers supposed to be in network byte order
(MSB).


On Wed, Jun 21, 2017 at 6:20 AM, 이두환 <letsme@gmail.com> wrote:

> IPv4 address can be just 4byte integer value.
> 10.10.10.10 means 0x0a0a0a0a and 20.20.20.20 means 0x14141414
> 10.10.10.30 is 0x0a0a0a1e and it is greater than 0x0a0a0a0a and less then
> 0x14141414.
> So, I think it should be matched but the result was not.
> Did I miss something?
>
> On Tue, Jun 20, 2017 at 5:58 PM, Shyam Shrivastav <
> shrivastav.shyam@gmail.com> wrote:
>
>> RTE_ACL_FIELD_TYPE_RANGE is for linear integer range like port numbers
>> For ip addresses RTE_ACL_FIELD_TYPE_MASK should be used.
>>
>> On Tue, Jun 20, 2017 at 1:57 PM, 이두환 <letsme@gmail.com> wrote:
>>
>>> Hello everyone.
>>>
>>> I want to implement some feature like ACL using DPDK ACL library.
>>> so, I defined rule like below.
>>>
>>> struct acl_match_component
>>> {
>>>     uint8_t protocol;
>>>     uint32_t sip;
>>>     uint32_t dip;
>>>     uint16_t sport;
>>>     uint16_t dport;
>>>     uint16_t in_if;
>>>     uint16_t out_if;
>>> }
>>>
>>>
>>> struct rte_acl_field_def ipv4_defs[7] = {
>>>     {
>>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>>         .size = sizeof(uint8_t),
>>>         .field_index = 0,
>>>         .input_index = 0,
>>>         .offset = 0
>>>     },
>>>     {
>>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>>         .size = sizeof(uint32_t),
>>>         .field_index = 1,
>>>         .input_index = 1,
>>>         .offset = offsetof(struct acl_match_component, sip)
>>>     },
>>>     {
>>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>>         .size = sizeof(uint32_t),
>>>         .field_index = 2,
>>>         .input_index = 2,
>>>         .offset = offsetof(struct acl_match_component, dip)
>>>     },
>>>     {
>>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>>         .size = sizeof(uint16_t),
>>>         .field_index = 3,
>>>         .input_index = 3,
>>>         .offset = offsetof(struct acl_match_component, sport)
>>>     },
>>>     {
>>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>>         .size = sizeof(uint16_t),
>>>         .field_index = 4,
>>>         .input_index = 3,
>>>         .offset = offsetof(struct acl_match_component, dport)
>>>     },
>>>     {
>>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>>         .size = sizeof(uint16_t),
>>>         .field_index = 5,
>>>         .input_index = 4,
>>>         .offset = offsetof(struct acl_match_component, in_if)
>>>     },
>>>     {
>>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>>         .size = sizeof(uint16_t),
>>>         .field_index = 6,
>>>         .input_index = 4,
>>>         .offset = offsetof(struct acl_match_component, out_if)
>>>     },
>>> };
>>>
>>> I defined 32bit IPv4 address filed as RTE_ACL_FIELD_TYPE_RANGE type.
>>> and I set rte_acl_field for IP field like below.
>>>
>>> value.u32 = IPv4(10,10,10,10);
>>> mask_range.u32 = IPv4(20,20,20,20);
>>>
>>> In this case, I think IP 10.10.10.15 and 10.10.10.30 should be matched.
>>> but result was IP 10.10.10.15 was matched and 10.10.10.30 was not
>>> matched.
>>>
>>> I am using DPDK 16.04 and there was no example in the DPDK source using
>>> 32bit field as range type.
>>> Range type with 16bit field (ex. port number) works well.
>>> And, DPDK 17.05 has no meaningful changes on ACL library compare to DPDK
>>> 16.04
>>>
>>> Do you have any idea about this?
>>>
>>> Thank you.
>>>
>>
>>
>

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

[Doohwan Lee]

Thank you for your opinion.
But I already checked byte ordering. It is used correctly like you
mentioned.
And, ACL library works good except 32bit matching with range type.

DPDK ACL library uses multi-bit trie with 8-bit stride.
I guess that implementation of the trie doesn't support 32bit range
matching.


On Wed, Jun 21, 2017 at 2:11 PM, Shyam Shrivastav <
shrivastav.shyam@gmail.com> wrote:

> Yes it can be but generally not used. Check dotted decimal IP address to
> integer conversion, ACL library expects host byte order while adding acl
> rules and network byte order while matching ..
>
> FROM ADD
>
> rules    : Array of rules to add to the ACL context. Note that all fields
> in rte_acl_rule structures are expected to be in host byte order. Each rule
> expected to be in the same format and not exceed size specified at ACL
> context creation time.
>
> FROM CLASSIFY
>
> data      : Array of pointers to input data buffers to perform search.
> Note that all fields in input data buffers supposed to be in network byte
> order (MSB).
>
>
> On Wed, Jun 21, 2017 at 6:20 AM, 이두환 <letsme@gmail.com> wrote:
>
>> IPv4 address can be just 4byte integer value.
>> 10.10.10.10 means 0x0a0a0a0a and 20.20.20.20 means 0x14141414
>> 10.10.10.30 is 0x0a0a0a1e and it is greater than 0x0a0a0a0a and less then
>> 0x14141414.
>> So, I think it should be matched but the result was not.
>> Did I miss something?
>>
>> On Tue, Jun 20, 2017 at 5:58 PM, Shyam Shrivastav <
>> shrivastav.shyam@gmail.com> wrote:
>>
>>> RTE_ACL_FIELD_TYPE_RANGE is for linear integer range like port numbers
>>> For ip addresses RTE_ACL_FIELD_TYPE_MASK should be used.
>>>
>>> On Tue, Jun 20, 2017 at 1:57 PM, 이두환 <letsme@gmail.com> wrote:
>>>
>>>> Hello everyone.
>>>>
>>>> I want to implement some feature like ACL using DPDK ACL library.
>>>> so, I defined rule like below.
>>>>
>>>> struct acl_match_component
>>>> {
>>>>     uint8_t protocol;
>>>>     uint32_t sip;
>>>>     uint32_t dip;
>>>>     uint16_t sport;
>>>>     uint16_t dport;
>>>>     uint16_t in_if;
>>>>     uint16_t out_if;
>>>> }
>>>>
>>>>
>>>> struct rte_acl_field_def ipv4_defs[7] = {
>>>>     {
>>>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>>>         .size = sizeof(uint8_t),
>>>>         .field_index = 0,
>>>>         .input_index = 0,
>>>>         .offset = 0
>>>>     },
>>>>     {
>>>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>>>         .size = sizeof(uint32_t),
>>>>         .field_index = 1,
>>>>         .input_index = 1,
>>>>         .offset = offsetof(struct acl_match_component, sip)
>>>>     },
>>>>     {
>>>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>>>         .size = sizeof(uint32_t),
>>>>         .field_index = 2,
>>>>         .input_index = 2,
>>>>         .offset = offsetof(struct acl_match_component, dip)
>>>>     },
>>>>     {
>>>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>>>         .size = sizeof(uint16_t),
>>>>         .field_index = 3,
>>>>         .input_index = 3,
>>>>         .offset = offsetof(struct acl_match_component, sport)
>>>>     },
>>>>     {
>>>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>>>         .size = sizeof(uint16_t),
>>>>         .field_index = 4,
>>>>         .input_index = 3,
>>>>         .offset = offsetof(struct acl_match_component, dport)
>>>>     },
>>>>     {
>>>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>>>         .size = sizeof(uint16_t),
>>>>         .field_index = 5,
>>>>         .input_index = 4,
>>>>         .offset = offsetof(struct acl_match_component, in_if)
>>>>     },
>>>>     {
>>>>         .type = RTE_ACL_FIELD_TYPE_RANGE,
>>>>         .size = sizeof(uint16_t),
>>>>         .field_index = 6,
>>>>         .input_index = 4,
>>>>         .offset = offsetof(struct acl_match_component, out_if)
>>>>     },
>>>> };
>>>>
>>>> I defined 32bit IPv4 address filed as RTE_ACL_FIELD_TYPE_RANGE type.
>>>> and I set rte_acl_field for IP field like below.
>>>>
>>>> value.u32 = IPv4(10,10,10,10);
>>>> mask_range.u32 = IPv4(20,20,20,20);
>>>>
>>>> In this case, I think IP 10.10.10.15 and 10.10.10.30 should be matched.
>>>> but result was IP 10.10.10.15 was matched and 10.10.10.30 was not
>>>> matched.
>>>>
>>>> I am using DPDK 16.04 and there was no example in the DPDK source using
>>>> 32bit field as range type.
>>>> Range type with 16bit field (ex. port number) works well.
>>>> And, DPDK 17.05 has no meaningful changes on ACL library compare to DPDK
>>>> 16.04
>>>>
>>>> Do you have any idea about this?
>>>>
>>>> Thank you.
>>>>
>>>
>>>
>>
>

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

[Anupam Kapoor]

On Wed, Jun 21, 2017 at 11:36 AM, Doohwan Lee <letsme@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.

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

[Doohwan Lee]

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@gmail.com>
wrote:

>
> On Wed, Jun 21, 2017 at 11:36 AM, Doohwan Lee <letsme@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.
>

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

[Shyam Shrivastav]

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

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

[Doohwan Lee]

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

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

[Shyam Shrivastav]

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

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

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

[Anupam Kapoor]

On Thu, Jun 22, 2017 at 11:28 AM, Doohwan Lee <letsme@gmail.com> wrote:

> Ok. The code to set rule for IPv4 address is like below.
>

​this is same as setting masks (1.0.0.0/8) :)

fwiw, beware of memory explosion in this case though...
​
--
kind regards
anupam​



In the beginning was the lambda, and the lambda was with Emacs, and Emacs
was the lambda.

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

[Shyam Shrivastav]

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

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

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

[Shyam Shrivastav]

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

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

Re: [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@dpdk.org

On Thu, Jun 22, 2017 at 12:57 PM, Doohwan Lee <letsme@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@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@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@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@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@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@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@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@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@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Jun 21, 2017 at 11:36 AM, Doohwan Lee <letsme@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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>