From: Ajit Khaparde <ajit.khaparde@broadcom.com> To: Bing Zhao <bingz@nvidia.com> Cc: Ori Kam <orika@nvidia.com>, Thomas Monjalon <thomas@monjalon.net>, Ferruh Yigit <ferruh.yigit@intel.com>, Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, Matan Azrad <matan@nvidia.com>, Slava Ovsiienko <viacheslavo@nvidia.com>, dpdk-dev <dev@dpdk.org>, Gregory Etelson <getelson@nvidia.com>, Andrey Vesnovaty <andreyv@nvidia.com> Subject: Re: [dpdk-dev] [PATCH v3 1/1] ethdev: introduce indirect action APIs Date: Thu, 15 Apr 2021 10:59:34 -0700 Message-ID: <CACZ4nhsy_bMkjGUvULvWqhHbnqZ55KvKqJoJzmiN-kcA-W5e6A@mail.gmail.com> (raw) In-Reply-To: <1618501912-92525-2-git-send-email-bingz@nvidia.com> [-- Attachment #1: Type: text/plain, Size: 3892 bytes --] On Thu, Apr 15, 2021 at 8:52 AM Bing Zhao <bingz@nvidia.com> wrote: > > Right now, rte_flow_shared_action_* APIs are used for some shared > actions, like RSS, count. The shared action should be created before > using it inside a flow. These shared actions sometimes are not > really shared but just some indirect actions decoupled from a flow. > > The new functions rte_flow_action_handle_* are added to replace > the current shared functions rte_flow_shared_action_*. > > There are two types of flow actions: > 1. the direct (normal) actions that could be created and stored > within a flow rule. Such action is tied to its flow rule and > cannot be reused. > 2. the indirect action, in the past, named shared_action. It is > created from a direct actioni, like count or rss, and then used > in the flow rules with an object handle. The PMD will take care > of the retrieve from indirect action to the direct action > when it is referenced. > > The indirect action is accessed (update / query) w/o any flow rule, > just via the action object handle. For example, when querying or > resetting a counter, it could be done out of any flow using this > counter, but only the handle of the counter action object is > required. > The indirect action object could be shared by different flows or > used by a single flow, depending on the direct action type and > the real-life requirements. > The handle of an indirect action object is opaque and defined in > each driver and possibly different per direct action type. > > The old name "shared" is improper in a sense and should be replaced. > > Since the APIs are changed from "rte_flow_shared_action*" to the new > "rte_flow_action_handle*", the testpmd application code and command > line interfaces also need to be updated to do the adaption. > The testpmd application user guide is also updated. All the "shared > action" related parts are replaced with "indirect action" to have a > correct explanation. > > The parameter of "update" interface is also changed. A general > pointer will replace the rte_flow_action struct pointer due to the > facts: > 1. Some action may not support fields updating. In the example of a > counter, the only "update" supported should be the reset. So > passing a rte_flow_action struct pointer is meaningless and > there is even no such corresponding action struct. What's more, > if more than one operations should be supported, for some other > action, such pointer parameter may not meet the need. > 2. Some action may need conditional or partial update, the current > parameter will not provide the ability to indicate which part(s) > to update. > For different types of indirect action objects, the pointer could > either be the same of rte_flow_action* struct - in order not to > break the current driver implementation, or some wrapper > structures with bits as masks to indicate which part to be > updated, depending on real needs of the corresponding direct > action. For different direct actions, the structures of indirect > action objects updating will be different. > > All the underlayer PMD callbacks will be moved to these new APIs. > > The RTE_FLOW_ACTION_TYPE_SHARED is kept for now in order not to > break the ABI. All the implementations are changed by using > RTE_FLOW_ACTION_TYPE_INDIRECT. When I read this somehow indirect did not feel right. But I don't have a strong suggestion either. Since it is a context of action or actions maybe we use action_context? > > Since the APIs are changed from "rte_flow_shared_action*" to the new > "rte_flow_action_handle*" and the "update" interface's 3rd input > parameter is changed to generic pointer, the mlx5 PMD that uses these > APIs needs to do the adaption to the new APIs as well. > > Signed-off-by: Bing Zhao <bingz@nvidia.com> > Acked-by: Andrey Vesnovaty <andreyv@nvidia.com>
next prev parent reply other threads:[~2021-04-15 17:59 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <1615967952-228321-1-git-send-email-bingz@nvidia.com> 2021-03-17 8:28 ` [dpdk-dev] [RFC] ethdev: introduce action context APIs Thomas Monjalon 2021-03-17 16:10 ` Bing Zhao 2021-03-22 14:59 ` Andrew Rybchenko 2021-04-06 9:05 ` Bing Zhao 2021-03-22 14:54 ` Andrew Rybchenko 2021-04-06 9:07 ` Bing Zhao 2021-04-06 9:48 ` Thomas Monjalon 2021-04-06 11:02 ` Bing Zhao 2021-04-06 12:18 ` Thomas Monjalon 2021-04-07 3:16 ` Ajit Khaparde 2021-04-07 6:11 ` Bing Zhao 2021-04-08 14:46 ` [dpdk-dev] [RFC PATCH v2] ethdev: introduce indirect action APIs Bing Zhao 2021-04-09 3:54 ` [dpdk-dev] [PATCH] " Bing Zhao 2021-04-10 14:03 ` [dpdk-dev] [PATCH v2 0/4] Change shared action API to action handle API Bing Zhao 2021-04-10 14:03 ` [dpdk-dev] [PATCH v2 1/4] ethdev: introduce indirect action APIs Bing Zhao 2021-04-12 19:42 ` Ferruh Yigit 2021-04-13 1:26 ` Bing Zhao 2021-04-13 14:00 ` Ori Kam 2021-04-13 12:36 ` Andrey Vesnovaty 2021-04-15 13:55 ` Andrew Rybchenko 2021-04-15 14:10 ` Thomas Monjalon 2021-04-15 16:02 ` Andrew Rybchenko 2021-04-10 14:03 ` [dpdk-dev] [PATCH v2 2/4] app/test-pmd: change to indirect action command Bing Zhao 2021-04-10 14:03 ` [dpdk-dev] [PATCH v2 3/4] doc: update user guide for indirect action Bing Zhao 2021-04-10 14:03 ` [dpdk-dev] [PATCH v2 4/4] net/mlx5: adaption to indirect action API Bing Zhao 2021-04-12 19:40 ` [dpdk-dev] [PATCH v2 0/4] Change shared action API to action handle API Ferruh Yigit 2021-04-13 1:22 ` Bing Zhao 2021-04-13 7:23 ` Thomas Monjalon 2021-04-13 7:24 ` Bing Zhao 2021-04-15 15:51 ` [dpdk-dev] [PATCH v3 0/1] " Bing Zhao 2021-04-15 15:51 ` [dpdk-dev] [PATCH v3 1/1] ethdev: introduce indirect action APIs Bing Zhao 2021-04-15 15:56 ` Ori Kam 2021-04-15 17:59 ` Ajit Khaparde [this message] 2021-04-16 6:58 ` Bing Zhao 2021-04-16 7:03 ` Thomas Monjalon 2021-04-16 15:00 ` Ajit Khaparde 2021-04-16 17:33 ` [dpdk-dev] [PATCH v4 0/1] Change shared action API to action handle API Bing Zhao 2021-04-16 17:33 ` [dpdk-dev] [PATCH v4 1/1] ethdev: introduce indirect action APIs Bing Zhao 2021-04-19 12:26 ` Thomas Monjalon 2021-04-19 15:05 ` Bing Zhao 2021-04-19 14:28 ` [dpdk-dev] [PATCH v5] Change shared action API to action handle API Bing Zhao 2021-04-19 14:28 ` [dpdk-dev] [PATCH v5] ethdev: introduce indirect action APIs Bing Zhao 2021-04-19 14:38 ` [dpdk-dev] [PATCH v5 0/1] Change shared action API to action handle API Bing Zhao 2021-04-19 14:38 ` [dpdk-dev] [PATCH v5 1/1] ethdev: introduce indirect action APIs Bing Zhao 2021-04-19 14:50 ` Thomas Monjalon 2021-04-19 15:09 ` Ferruh Yigit
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CACZ4nhsy_bMkjGUvULvWqhHbnqZ55KvKqJoJzmiN-kcA-W5e6A@mail.gmail.com \ --to=ajit.khaparde@broadcom.com \ --cc=andrew.rybchenko@oktetlabs.ru \ --cc=andreyv@nvidia.com \ --cc=bingz@nvidia.com \ --cc=dev@dpdk.org \ --cc=ferruh.yigit@intel.com \ --cc=getelson@nvidia.com \ --cc=matan@nvidia.com \ --cc=orika@nvidia.com \ --cc=thomas@monjalon.net \ --cc=viacheslavo@nvidia.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
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