From: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
To: <dev@dpdk.org>
Cc: David Marchand <david.marchand@redhat.com>, <bingz@nvidia.com>,
<stable@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: [dpdk-dev] [PATCH 4/4] ethdev: document indirect flow action life cycle
Date: Tue, 27 Jul 2021 10:31:20 +0300 [thread overview]
Message-ID: <20210727073121.895620-5-dkozlyuk@nvidia.com> (raw)
In-Reply-To: <20210727073121.895620-1-dkozlyuk@nvidia.com>
rte_flow_action_handle_create() did not specify what happens
with an indirect action when device is stopped, possibly reconfigured,
and started again.
It is proposed that indirect actions persisted across such a sequence.
This allows for easier API usage and better HW resources utilization
by saving indirect actions flush and re-creation with associated error
handling and rollback.
If between stop and start a device is reconfigured in a way that is
incompatible with an existing indirect action, PMD is required to report
an error at the device start. 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. Errors are not reported
at configuration stage to give the user a chance to remove or change
offending actions. For example, if number of queues changes and an RSS
indirect action specifies queues that went away, user must update
the action before starting the device. PMD is not allowed to silently
adjust indirect actions (in the same example, to remove queues from
the RSS), so that all configuration is explicit.
Fixes: 4b61b8774be9 ("ethdev: introduce indirect flow action")
Cc: bingz@nvidia.com
Cc: stable@dpdk.org
Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
---
doc/guides/prog_guide/rte_flow.rst | 10 ++++++++++
lib/ethdev/rte_flow.h | 4 ++++
2 files changed, 14 insertions(+)
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 2b42d5ec8c..06dd06d9a6 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -2785,6 +2785,16 @@ 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()``.
+Indirect actions persist across device configure, stop, and start.
+If a new configuration is incompatible with an existing indirect action,
+the start operation will fail. "Incompatible" means that if this action
+was destroyed and created again, creation would fail.
+It is a programmer's responsibility to remove or update offending actions.
+
+PMD developers should use the same diagnostics for ``rte_eth_dev_start()``
+as for ``rte_flow_action_handle_create()``. PMD is not allowed to silently
+ignore or correct offending actions.
+
.. _table_rte_flow_action_handle:
.. table:: INDIRECT
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 70f455d47d..f571a27fe7 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -3969,6 +3969,10 @@ struct rte_flow_indir_action_conf {
* The created object handle has single state and configuration
* across all the flow rules using it.
*
+ * Indirect actions persist across device configure, stop, and start.
+ * If a new configuration is incompatible with an existing indirect
+ * action, rte_eth_dev_start() will fail.
+ *
* @param[in] port_id
* The port identifier of the Ethernet device.
* @param[in] conf
--
2.25.1
next prev parent reply other threads:[~2021-07-27 7:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-27 7:31 [dpdk-dev] [PATCH 0/4] net/mlx5: keep indirect actions across port restart Dmitry Kozlyuk
2021-07-27 7:31 ` [dpdk-dev] [PATCH 1/4] net/mlx5: discover max flow priority using DevX Dmitry Kozlyuk
2021-07-27 7:31 ` [dpdk-dev] [PATCH 2/4] net/mlx5: create drop queue " Dmitry Kozlyuk
2021-07-27 7:31 ` [dpdk-dev] [PATCH 3/4] net/mlx5: preserve indirect actions across port restart Dmitry Kozlyuk
2021-07-27 7:31 ` Dmitry Kozlyuk [this message]
2021-07-28 9:50 ` [dpdk-dev] [PATCH 4/4] ethdev: document indirect flow action life cycle Ori Kam
2021-07-28 8:05 ` [dpdk-dev] [PATCH 0/4] net/mlx5: keep indirect actions across port restart Andrew Rybchenko
2021-07-28 11:18 ` Dmitry Kozlyuk
2021-07-28 12:07 ` Ori Kam
2021-07-28 12:26 ` Andrew Rybchenko
2021-07-28 14:08 ` Dmitry Kozlyuk
2021-07-28 17:07 ` Ori Kam
2021-07-29 14:00 ` [dpdk-dev] [PATCH v2 " Dmitry Kozlyuk
2021-07-29 14:00 ` [dpdk-dev] [PATCH v2 1/3] net/mlx5: discover max flow priority using DevX Dmitry Kozlyuk
2021-07-29 14:00 ` [dpdk-dev] [PATCH v2 2/3] net/mlx5: create drop queue " Dmitry Kozlyuk
2021-07-29 14:00 ` [dpdk-dev] [PATCH v2 3/3] net/mlx5: preserve indirect actions across port restart Dmitry Kozlyuk
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=20210727073121.895620-5-dkozlyuk@nvidia.com \
--to=dkozlyuk@nvidia.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=bingz@nvidia.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=matan@nvidia.com \
--cc=orika@nvidia.com \
--cc=stable@dpdk.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).