Bug 995 - acl: field size=8 (u64) is not working
Summary: acl: field size=8 (u64) is not working
Status: IN_PROGRESS
Alias: None
Product: DPDK
Classification: Unclassified
Component: other (show other bugs)
Version: 21.11
Hardware: All All
: Normal normal
Target Milestone: ---
Assignee: dev
URL:
Depends on:
Blocks:
 
Reported: 2022-04-17 19:56 CEST by ido goshen
Modified: 2022-05-11 15:27 CEST (History)
1 user (show)



Attachments
test-acl app patch that adds u64 field and input files (6.54 KB, application/mbox)
2022-04-17 19:56 CEST, ido goshen
Details
simple example app for acl with u64 field (2.89 KB, text/x-csrc)
2022-04-17 20:04 CEST, ido goshen
Details

Description ido goshen 2022-04-17 19:56:06 CEST
Created attachment 199 [details]
test-acl app patch that adds u64 field and input files

Hi

ACL with field size 8 (for u64) is not working

    struct rte_acl_field_def acl_fields[] =
    {
    ...
        {
            ...
            .size = sizeof(uint64_t),
            ...
        }
    ...
    }

Attached are 2 examples:

1. test-acl-64.patch -
It slightly expands the existing test-acl app with an u64 field
When using a rule that the u64 field is don't care (mask is all 0) it passes
    bash app/test-acl/test-acl.sh build/app/dpdk-test-acl app/test-acl/input_u64_mask_0/ scalar 32
    ACL: trie 0: number of rules: 1, indexes: 3
    test acl1v4_1_rule OK
But when using a rule with u64 value that should match it fails
    bash app/test-acl/test-acl.sh build/app/dpdk-test-acl app/test-acl/input_u64_mask_F/ scalar 32
    ACL: trie 0: number of rules: 1, indexes: 4
    --- acl1v4_1_rule_E6Gkks.chk	2022-04-17 20:39:25.803425601 +0300
    +++ acl1v4_1_rule_E6Gkks.out	2022-04-17 20:39:25.803425601 +0300
    @@ -1 +1 @@
    -0
    +4294967295
    test acl1v4_1_rule FAILED

2. acl-test-64.c
a small standalone app (can be compiled like any dpdk/example) with simple 2 fields ACL (the mandatory first one byte field + an u64 field) with hard-coded values that should match but do not. 
it can be run w/o any params
    examples/acl-test-u64/build/acl-test-u64 --no-huge -c 1
    NO-MATCH - test FAILED! 

notes:
1. It doesn't work for RTE_ACL_FIELD_TYPE_RANGE/MASK too
2. Looks like if using only the 4 MSBs and masking the 4 LSBs (e.g. mask = 0xFFFFFFFF00000000) it does work 

Thanx,
Ido
Comment 1 ido goshen 2022-04-17 20:04:12 CEST
Created attachment 200 [details]
simple example app for acl with u64 field

if the acl-test-u64 app is slightly changed to use u32 field instead u64 then it does work
e.g. 
    sed -i 's/64/32/' examples/acl-test-u64/acl-test-u64.c 
    cgs@idog-ubuntu:~/dpdk-stable$ git diff -U0
    diff --git a/examples/acl-test-u64/acl-test-u64.c b/examples/acl-test-u64/acl-test-u64.c
    index 3a2d23daf6..eec6d6e0d0 100644
    --- a/examples/acl-test-u64/acl-test-u64.c
    +++ b/examples/acl-test-u64/acl-test-u64.c
    @@ -2 +2 @@
    - * acl-test-64.c
    + * acl-test-32.c
    @@ -16 +16 @@ struct acl_data
    -       uint64_t value;
    +       uint32_t value;
    @@ -32 +32 @@ struct rte_acl_field_def acl_fields[] =
    -                               .size = sizeof(uint64_t),
    +                               .size = sizeof(uint32_t),
    @@ -52 +52 @@ add_rules(struct acl_rule **pacl_base,
    -                                       .field[1] = { .value.u64 = VALUE, 
    .mask_range.u64 = MASK },
    +                                       .field[1] = { .value.u32 = VALUE, 
    .mask_range.u32 = MASK },
    @@ -103 +103 @@ static const struct acl_data* data_init()
    -       data[0].value = rte_cpu_to_be_64(VALUE);
    +       data[0].value = rte_cpu_to_be_32(VALUE);

it does work
     examples/acl-test-u64/build/acl-test-u64 --no-huge -c 1
     MATCH - test PASSED
Comment 2 Konstantin Ananyev 2022-04-28 15:53:53 CEST
Please give it a try:
http://patchwork.dpdk.org/project/dpdk/list/?series=22676
Comment 3 ido goshen 2022-05-11 15:27:44 CEST
The patch good
Tested variety of long fields (mac-address, ipv6, imsi) with FIELD_TYPE BITMASK and RANGE

Note You need to log in before you can comment on or make changes to this bug.