DPDK patches and discussions
 help / color / mirror / Atom feed
From: Jerin Jacob <jerinjacobk@gmail.com>
To: Andrey Vesnovaty <andrey.vesnovaty@gmail.com>
Cc: Thomas Monjalon <thomas@monjalon.net>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	 Andrew Rybchenko <arybchenko@solarflare.com>,
	Ori Kam <orika@mellanox.com>, dpdk-dev <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC] add flow action context API
Date: Wed, 3 Jun 2020 16:23:03 +0530
Message-ID: <CALBAE1Os+GG7UTRYVtiqcaHERPvaM6Ge+HeBF-fj=oM6STdPGg@mail.gmail.com> (raw)
In-Reply-To: <20200520091801.30163-1-andrey.vesnovaty@gmail.com>

On Wed, May 20, 2020 at 2:48 PM Andrey Vesnovaty
<andrey.vesnovaty@gmail.com> wrote:
>
> This commit introduces extension of DPDK flow action API enabling
> modification of single rte_flow_action.
>
> Motivation and example
> ===
> Adding or removing one or more queues to RSS actions cloned in multiple
> flow rules imposes per rule toll for current DPDK flow API; the scenario
> requires for each flow sharing cloned RSS action:
> - call `rte_flow_destroy()`
> - call `rte_flow_create()` with modified RSS action
>
> In order to prevent the overhead of multiple RSS flow rules reconfiguration
> API for in-place flow action modification introduced in this commit.
>
> Change description
> ===
> Provide an API to create single rte_flow_action context to point/reference
> rte_flow_action object contents from multiple rte_flow_rule objects.
> Actually the introduced API makes action object shared and modification
> of such an action effects all the rules referencing the action via context
> (see struct rte_flow_action_ctx).
>
> Action context lifetime
> ---
> Once action context created (see rte_flow_action_ctx_create()) it can be
> safely reused for:
> - new flow rule creation
> - action configuration/state modification
>   (see rte_flow_action_ctx_modify())
> - action state query (see rte_flow_action_ctx_query())
> Once rte_flow_action_ctx_destroy() called the destroyed action context
> should not be used i.e. result of the usage undefined.

Motivation makes sense to me. It will be an improvement.

But creating shared objects adds additional complexity to "PMD and
application" as it
needs to manage the state. Since rte_flow_action already expressed in
vendor natural format,  What will be the benefit of a shared context?

Would the following additional API suffice the motivation?

rte_flow_modify_action(struct rte_flow * flow,  const struct
rte_flow_action actions[])

  parent reply	other threads:[~2020-06-03 10:53 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20  9:18 Andrey Vesnovaty
2020-06-03 10:02 ` Thomas Monjalon
2020-06-04 11:12   ` Andrey Vesnovaty
2020-06-04 17:23     ` Thomas Monjalon
2020-06-05  8:30       ` Bruce Richardson
2020-06-05  8:33         ` Thomas Monjalon
2020-06-03 10:53 ` Jerin Jacob [this message]
2020-06-04 11:25   ` Andrey Vesnovaty
2020-06-04 12:36     ` Jerin Jacob
2020-06-04 15:57       ` Andrey Vesnovaty
2020-06-09 16:01         ` Jerin Jacob
2020-06-20 13:32           ` [dpdk-dev] [RFC v2 0/1] " Andrey Vesnovaty
2020-06-22 15:22             ` Thomas Monjalon
2020-06-22 17:09               ` Andrey Vesnovaty
2020-06-26 11:44             ` Jerin Jacob
2020-06-28  8:44               ` Andrey Vesnovaty
2020-06-28 13:42                 ` Jerin Jacob
2020-06-29 10:22                   ` Andrey Vesnovaty
2020-06-30  9:52                     ` Jerin Jacob
2020-07-01  9:24                       ` Andrey Vesnovaty
2020-07-01 10:34                         ` Jerin Jacob
2020-06-20 13:32           ` [dpdk-dev] [RFC v2 1/1] add flow shared action API Andrey Vesnovaty
2020-07-02  0:24             ` Stephen Hemminger
2020-07-02  7:20               ` Ori Kam
2020-07-02  8:06                 ` Andrey Vesnovaty

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='CALBAE1Os+GG7UTRYVtiqcaHERPvaM6Ge+HeBF-fj=oM6STdPGg@mail.gmail.com' \
    --to=jerinjacobk@gmail.com \
    --cc=andrey.vesnovaty@gmail.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=orika@mellanox.com \
    --cc=thomas@monjalon.net \
    /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