DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] ACL priority field
@ 2020-01-27 21:42 Bly, Mike
  2020-01-29 14:03 ` Ananyev, Konstantin
  0 siblings, 1 reply; 3+ messages in thread
From: Bly, Mike @ 2020-01-27 21:42 UTC (permalink / raw)
  To: dev

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-dev] ACL priority field
  2020-01-27 21:42 [dpdk-dev] ACL priority field Bly, Mike
@ 2020-01-29 14:03 ` Ananyev, Konstantin
  2020-01-29 16:30   ` Bly, Mike
  0 siblings, 1 reply; 3+ messages in thread
From: Ananyev, Konstantin @ 2020-01-29 14:03 UTC (permalink / raw)
  To: Bly, Mike, dev; +Cc: Dumitrescu, Cristian

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;



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [dpdk-dev] ACL priority field
  2020-01-29 14:03 ` Ananyev, Konstantin
@ 2020-01-29 16:30   ` Bly, Mike
  0 siblings, 0 replies; 3+ messages in thread
From: Bly, Mike @ 2020-01-29 16:30 UTC (permalink / raw)
  To: Ananyev, Konstantin, dev; +Cc: Dumitrescu, Cristian

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;



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-01-29 16:30 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-27 21:42 [dpdk-dev] ACL priority field Bly, Mike
2020-01-29 14:03 ` Ananyev, Konstantin
2020-01-29 16:30   ` Bly, Mike

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git