DPDK patches and discussions
 help / color / mirror / Atom feed
From: Gregory Etelson <getelson@nvidia.com>
To: <getelson@nvidia.com>
Cc: <dev@dpdk.org>, <matan@nvidia.com>, <thomas@monjalon.net>,
	<andrew.rybchenko@oktetlabs.ru>, Ori Kam <orika@nvidia.com>
Subject: [dpdk-dev] [PATCH v2] doc: flow rule removal on port stop
Date: Wed, 18 Nov 2020 18:15:20 +0200	[thread overview]
Message-ID: <20201118161520.4378-1-getelson@nvidia.com> (raw)
In-Reply-To: <20200916111854.1949-1-getelson@nvidia.com>

There is a discrepancy between RTE ETHDEV API and flow rules guide
regarding flow rules maintenance after port stop.  RTE ETHDEV API in
librte_ethdev.h declares that flow rules will not be stored in PMD
after port stop:
 >>>>> Quite start
 Please note that some configuration is not stored between calls to
 rte_eth_dev_stop()/rte_eth_dev_start(). The following configuration
 will be retained:

 - MTU
 - flow control settings
 - receive mode configuration (promiscuous mode, all-multicast mode,
   hardware checksum mode, RSS/VMDQ settings etc.)
 - VLAN filtering configuration
 - default MAC address
 - MAC addresses supplied to MAC address array
 - flow director filtering mode (but not filtering rules)
 - NIC queue statistics mappings
 <<<< Quote end

PMD cannot always correctly restore flow rules after port stop / port
start because application may alter port configuration after port stop
without PMD knowledge about undergoing changes.  Consider the
following scenario:
application configures 2 queues 0 and 1 and creates a flow rule with
'queue index 1' action. After that application stops the port and
removes queue 1.
Although PMD can implement flow rule shadow copy to be used for
restore after port start, attempt to restore flow rule from shadow
will fail in example above and PMD could not notify application about
that failure.  As the result, flow rules map in HW will differ from
what application expects.  In addition, flow rules shadow copy used
for port start restore consumes considerable amount of system memory,
especially in systems with millions of flow rules.

Signed-off-by: Gregory Etelson <getelson@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
---
 doc/guides/prog_guide/rte_flow.rst | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index ea203e0ca4..4cff9332fa 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -3229,10 +3229,12 @@ Caveats
   temporarily replacing the burst function pointers), an appropriate error
   code must be returned (``EBUSY``).
 
-- PMDs, not applications, are responsible for maintaining flow rules
-  configuration when stopping and restarting a port or performing other
-  actions which may affect them. They can only be destroyed explicitly by
-  applications.
+- Applications, not PMDs, are responsible for maintaining flow rules
+  configuration when closing, stopping or restarting a port or performing other
+  actions which may affect them.
+  Applications must assume that after port close, stop or restart all flows
+  related to that port are not valid, hardware rules are destroyed and relevant
+  PMD resources are released.
 
 For devices exposing multiple ports sharing global settings affected by flow
 rules:
-- 
2.29.2


  parent reply	other threads:[~2020-11-18 16:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-16 11:18 [dpdk-dev] [PATCH] " Gregory Etelson
2020-11-17 19:18 ` Gregory Etelson
2020-11-17 19:56   ` Andrew Rybchenko
2020-11-18  8:59     ` Gregory Etelson
2020-11-18  9:04       ` Andrew Rybchenko
2020-11-18  9:06         ` Gregory Etelson
2020-11-18 16:15 ` Gregory Etelson [this message]
2020-11-22 16:55   ` [dpdk-dev] [PATCH v2] " Thomas Monjalon
2020-11-24 11:04     ` Thomas Monjalon
2020-11-24 14:41   ` Ajit Khaparde
2020-11-25 23:33     ` 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=20201118161520.4378-1-getelson@nvidia.com \
    --to=getelson@nvidia.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --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 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).