[dpdk-dev] ACL priority field

[dpdk-dev] ACL priority field

[Bly, Mike]

Hello,

Can someone clarify what I am interpreting  as a documentation conflict regarding the "priority" field for rte_table_acl_rule_add_params? Below documentation says "highest priority wins", but the header file comment says 0 is highest priority. Based on my testing with conflicting entries, I would like ask if we can/should update the documentation/descriptions to state "the lowest non-negative integer priority value will be selected". Highest priority implies select X, when X > Y >= 0. However, based on my testing, that is not the case. Instead, Y is selected.

From: https://doc.dpdk.org/guides/prog_guide/packet_classif_access_ctrl.html

When creating a set of rules, for each rule, additional information must be supplied also:
*         priority: A weight to measure the priority of the rules (higher is better)... If the input tuple matches more than one rule, then the rule with the higher priority is returned. Note that if the input tuple matches more than one rule and these rules have equal priority, it is undefined which rule is returned as a match. It is recommended to assign a unique priority for each rule.
From: http://doc.dpdk.org/api/structrte__table__acl__rule__add__params.html

int32_t priority
ACL rule priority, with 0 as the highest priority
Regards,
Mike

Re: [dpdk-dev] ACL priority field

[Ananyev, Konstantin]

Hi,

> 
> Hello,
> 
> Can someone clarify what I am interpreting  as a documentation conflict regarding the "priority" field for rte_table_acl_rule_add_params?
> Below documentation says "highest priority wins", but the header file comment says 0 is highest priority. Based on my testing with
> conflicting entries, I would like ask if we can/should update the documentation/descriptions to state "the lowest non-negative integer
> priority value will be selected". Highest priority implies select X, when X > Y >= 0. However, based on my testing, that is not the case.
> Instead, Y is selected.
> 
> From: https://doc.dpdk.org/guides/prog_guide/packet_classif_access_ctrl.html
> 
> When creating a set of rules, for each rule, additional information must be supplied also:
> *         priority: A weight to measure the priority of the rules (higher is better)... If the input tuple matches more than one rule, then the rule
> with the higher priority is returned. Note that if the input tuple matches more than one rule and these rules have equal priority, it is
> undefined which rule is returned as a match. It is recommended to assign a unique priority for each rule.
> From: http://doc.dpdk.org/api/structrte__table__acl__rule__add__params.html
> 
> int32_t priority
> ACL rule priority, with 0 as the highest priority

I think you are mixing 2 different entities here:
librte_acl and librte_table.
For librte_acl - higher priority wins. 
librte_table_acl.c uses librte_acl inside,
but AFAIK has reverse ordering for priority:
'lesser priority wins'.
Inside it reverts rules priority before adding it
into the ACL lib ctx. 

static int
rte_table_acl_entry_add(
        void *table,
        void *key,
        void *entry,
        int *key_found,
        void **entry_ptr)
{
   ...
  if (rule->priority > RTE_ACL_MAX_PRIORITY) {
                RTE_LOG(ERR, TABLE, "%s: Priority is too high\n", __func__);
                return -EINVAL;
        }

        /* Setup rule data structure */
        memset(&acl_rule, 0, sizeof(acl_rule));
        ...
        acl_rule.data.priority = RTE_ACL_MAX_PRIORITY - rule->priority;

Re: [dpdk-dev] ACL priority field

[Bly, Mike]

Konstantin,

Ah, I see now. Yes, we are using rte_table_acl. Is there a reason these two differ in precedence selection?

Regards,
Mike

********************************

Hi,

> 
> Hello,
> 
> Can someone clarify what I am interpreting  as a documentation conflict regarding the "priority" field for rte_table_acl_rule_add_params?
> Below documentation says "highest priority wins", but the header file 
> comment says 0 is highest priority. Based on my testing with 
> conflicting entries, I would like ask if we can/should update the documentation/descriptions to state "the lowest non-negative integer priority value will be selected". Highest priority implies select X, when X > Y >= 0. However, based on my testing, that is not the case.
> Instead, Y is selected.
> 
> From: 
> https://doc.dpdk.org/guides/prog_guide/packet_classif_access_ctrl.html
> 
> When creating a set of rules, for each rule, additional information must be supplied also:
> *         priority: A weight to measure the priority of the rules (higher is better)... If the input tuple matches more than one rule, then the rule
> with the higher priority is returned. Note that if the input tuple 
> matches more than one rule and these rules have equal priority, it is undefined which rule is returned as a match. It is recommended to assign a unique priority for each rule.
> From: 
> http://doc.dpdk.org/api/structrte__table__acl__rule__add__params.html
> 
> int32_t priority
> ACL rule priority, with 0 as the highest priority

I think you are mixing 2 different entities here:
librte_acl and librte_table.
For librte_acl - higher priority wins. 
librte_table_acl.c uses librte_acl inside, but AFAIK has reverse ordering for priority:
'lesser priority wins'.
Inside it reverts rules priority before adding it into the ACL lib ctx. 

static int
rte_table_acl_entry_add(
        void *table,
        void *key,
        void *entry,
        int *key_found,
        void **entry_ptr)
{
   ...
  if (rule->priority > RTE_ACL_MAX_PRIORITY) {
                RTE_LOG(ERR, TABLE, "%s: Priority is too high\n", __func__);
                return -EINVAL;
        }

        /* Setup rule data structure */
        memset(&acl_rule, 0, sizeof(acl_rule));
        ...
        acl_rule.data.priority = RTE_ACL_MAX_PRIORITY - rule->priority;