All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ajit Khaparde <ajit.khaparde@broadcom.com>
To: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
Cc: dpdk-dev <dev@dpdk.org>, Matan Azrad <matan@nvidia.com>,
	Ori Kam <orika@nvidia.com>,
	 Thomas Monjalon <thomas@monjalon.net>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	 Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ethdev: add capability to keep indirect actions on restart
Date: Wed, 6 Oct 2021 10:12:43 -0700	[thread overview]
Message-ID: <CACZ4nhvNcH5Pjs1dhTTmffJan5E-SUiPg=eL41cEpOZaS+DCQg@mail.gmail.com> (raw)
In-Reply-To: <20210901085516.3647814-3-dkozlyuk@nvidia.com>

[-- Attachment #1: Type: text/plain, Size: 4079 bytes --]

On Wed, Sep 1, 2021 at 1:55 AM Dmitry Kozlyuk <dkozlyuk@nvidia.com> wrote:
>
> rte_flow_action_handle_create() did not mention what happens
> with an indirect action when a device is stopped, possibly reconfigured,
> and started again. It is natural for some indirect actions to be
> persistent, like counters and meters; keeping others just saves
> application time and complexity. However, not all PMDs can support it.
> It is proposed to add a device capability to indicate if indirect actions
> are kept across the above sequence or implicitly destroyed.
>
> It may happen that in the future a PMD acquires support for a type of
> indirect actions that it cannot keep across a restart. It is undesirable
> to stop advertising the capability so that applications that don't use
> actions of the problematic type can still take advantage of it.
> This is why PMDs are allowed to keep only a subset of indirect actions
> provided that the vendor mandatorily documents it.
Sorry - I am seeing this late.
This could become confusing.
May be it is better for the PMDs to specify which actions are persistent.
How about adding a bit for the possible actions of interest.
And then PMDs can set bits for actions which can be persistent across
stop, start and reconfigurations?

>
> If the device is being reconfigured in a way that is incompatible with
> an existing indirect action, PMD is required to report an error.
> This is mandatory, because flow API does not supply users with
> capabilities, so this is the only way for a user to learn that
> configuration is invalid. For example, if queue count changes and RSS
> indirect action specifies queues that are going away, the user must
> update the action before removing the queues or remove the action and
> all flow rules that were using it.
>
> Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
> Acked-by: Matan Azrad <matan@nvidia.com>
> Acked-by: Ori Kam <orika@nvidia.com>
> ---
>  doc/guides/prog_guide/rte_flow.rst | 12 ++++++++++++
>  lib/ethdev/rte_ethdev.h            |  5 +++++
>  2 files changed, 17 insertions(+)
>
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 0a03097a7c..da90b52f48 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -2794,6 +2794,18 @@ updated depend on the type of the ``action`` and different for every type.
>  The indirect action specified data (e.g. counter) can be queried by
>  ``rte_flow_action_handle_query()``.
>
> +By default indirect actions are destroyed when the device is stopped.
> +If the device advertises ``RTE_ETH_DEV_CAPA_FLOW_INDIRECT_ACTION_KEEP``,
> +indirect actions persist across the device stop and start with possible
> +reconfiguration in between. Some configuration changes may be incompatible
> +with existing indirect actions, in this case ``rte_eth_dev_configure()`` and/or
> +``rte_eth_rx/tx_queue_setup()`` will fail. At this point PMD developers
> +are encouraged to log errors identical to the ones that would be emitted by
> +``rte_flow_action_handle_create()`` if the new configuration was active.
> +Even if this capability is advertised, there may be kinds of indirect actions
> +that the device cannot keep. They are implicitly destroyed at device stop.
> +PMD developers must document such kinds of actions if applicable.
> +
>  .. _table_rte_flow_action_handle:
>
>  .. table:: INDIRECT
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index 1616bdf2dd..c3be5afcb2 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -1450,6 +1450,11 @@ struct rte_eth_conf {
>  #define RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP 0x00000002
>  /** Device keeps flow rules across restart and reconfiguration. */
>  #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP 0x00000004
> +/**
> + * Device keeps indirect actions across restart and reconfiguration.
> + * For a specific PMD this may not be applicable to certain action types.
> + */
> +#define RTE_ETH_DEV_CAPA_FLOW_INDIRECT_ACTION_KEEP 0x00000008
>  /**@}*/
>
>  /*
> --
> 2.25.1
>

  parent reply	other threads:[~2021-10-06 17:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01  8:55 [dpdk-dev] [RFC PATCH 0/2] Flow entities behavior across port restart Dmitry Kozlyuk
2021-09-01  8:55 ` [dpdk-dev] [RFC PATCH 1/2] ethdev: add capability to keep flow rules on restart Dmitry Kozlyuk
2021-09-01  8:55 ` [dpdk-dev] [RFC PATCH 2/2] ethdev: add capability to keep indirect actions " Dmitry Kozlyuk
2021-09-27 11:21   ` Dmitry Kozlyuk
2021-10-06 17:12   ` Ajit Khaparde [this message]
2021-10-07  8:16     ` Dmitry Kozlyuk
2021-10-11 13:58       ` Andrew Rybchenko
2021-10-11 15:53         ` Ori Kam
2021-10-12  9:15           ` Andrew Rybchenko
2021-10-12 10:26             ` Ori Kam
2021-10-12 10:41               ` Andrew Rybchenko
2021-10-13  8:36                 ` Dmitry Kozlyuk
2021-10-11 15:57         ` Dmitry Kozlyuk
2021-10-05 17:23 ` [dpdk-dev] [RFC PATCH 0/2] Flow entities behavior across port restart Thomas Monjalon

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='CACZ4nhvNcH5Pjs1dhTTmffJan5E-SUiPg=eL41cEpOZaS+DCQg@mail.gmail.com' \
    --to=ajit.khaparde@broadcom.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=dkozlyuk@nvidia.com \
    --cc=ferruh.yigit@intel.com \
    --cc=matan@nvidia.com \
    --cc=orika@nvidia.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.