All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Daley <johndale@cisco.com>
To: john.mcnamara@intel.com
Cc: adrien.mazarguil@6wind.com, dev@dpdk.org,
	John Daley <johndale@cisco.com>
Subject: [PATCH v4] doc: fix flow validate comments
Date: Thu, 20 Apr 2017 11:49:33 -0700	[thread overview]
Message-ID: <20170420184933.27450-1-johndale@cisco.com> (raw)
In-Reply-To: <20170407002300.14433-1-johndale@cisco.com>

Change comments for rte_flow_validate() function to indicate that flow
rule collision and resource validation is optional for PMDs and
therefore the return codes may have different meanings.

Fixes: b1a4b4cbc0a8 ("ethdev: introduce generic flow API")

Signed-off-by: John Daley <johndale@cisco.com>
---
v2: another crack at the comments
v3: fix typos, rewording, put back a sentence omitted in v2
v4: fixes per Adrien Mazarguil- update guide, typo, commit title

 doc/guides/prog_guide/rte_flow.rst | 17 ++++++++++++-----
 lib/librte_ether/rte_flow.h        | 16 +++++++++++-----
 2 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 5ee045ee8..9f3d3b096 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1332,9 +1332,11 @@ supported and can be created.
                      const struct rte_flow_action actions[],
                      struct rte_flow_error *error);
 
-While this function has no effect on the target device, the flow rule is
-validated against its current configuration state and the returned value
-should be considered valid by the caller for that state only.
+The flow rule is validated for correctness and whether it could be accepted
+by the device given sufficient resources. The rule is checked against the
+current device mode and queue configuration. The flow rule may also
+optionally be validated against existing flow rules and device resources.
+This function has no effect on the target device.
 
 The returned value is guaranteed to remain valid only as long as no
 successful calls to ``rte_flow_create()`` or ``rte_flow_destroy()`` are made
@@ -1360,8 +1362,13 @@ Return values:
 - ``-EINVAL``: unknown or invalid rule specification.
 - ``-ENOTSUP``: valid but unsupported rule specification (e.g. partial
   bit-masks are unsupported).
-- ``-EEXIST``: collision with an existing rule.
-- ``-ENOMEM``: not enough resources.
+- ``EEXIST``: collision with an existing rule. Only returned if device
+  supports flow rule collision checking and there was a flow rule
+  collision. Not receiving this return code is no guarantee that creating
+  the rule will not fail due to a collision.
+- ``ENOMEM``: not enough memory to execute the function, or if the device
+  supports resource validation, resource limitation on the device.
+
 - ``-EBUSY``: action cannot be performed due to busy device resources, may
   succeed if the affected queues or even the entire port are in a stopped
   state (see ``rte_eth_dev_rx_queue_stop()`` and ``rte_eth_dev_stop()``).
diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
index 8013ecab2..7749491cb 100644
--- a/lib/librte_ether/rte_flow.h
+++ b/lib/librte_ether/rte_flow.h
@@ -983,9 +983,11 @@ struct rte_flow_error {
 /**
  * Check whether a flow rule can be created on a given port.
  *
- * While this function has no effect on the target device, the flow rule is
- * validated against its current configuration state and the returned value
- * should be considered valid by the caller for that state only.
+ * The flow rule is validated for correctness and whether it could be accepted
+ * by the device given sufficient resources. The rule is checked against the
+ * current device mode and queue configuration. The flow rule may also
+ * optionally be validated against existing flow rules and device resources.
+ * This function has no effect on the target device.
  *
  * The returned value is guaranteed to remain valid only as long as no
  * successful calls to rte_flow_create() or rte_flow_destroy() are made in
@@ -1016,9 +1018,13 @@ struct rte_flow_error {
  *   -ENOTSUP: valid but unsupported rule specification (e.g. partial
  *   bit-masks are unsupported).
  *
- *   -EEXIST: collision with an existing rule.
+ *   -EEXIST: collision with an existing rule. Only returned if device
+ *   supports flow rule collision checking and there was a flow rule
+ *   collision. Not receiving this return code is no guarantee that creating
+ *   the rule will not fail due to a collision.
  *
- *   -ENOMEM: not enough resources.
+ *   -ENOMEM: not enough memory to execute the function, or if the device
+ *   supports resource validation, resource limitation on the device.
  *
  *   -EBUSY: action cannot be performed due to busy device resources, may
  *   succeed if the affected queues or even the entire port are in a stopped
-- 
2.12.0

  parent reply	other threads:[~2017-04-20 18:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-24  2:36 [PATCH 0/1] proposed minor change in rte_flow_validate semantics John Daley
2017-03-24  2:36 ` [PATCH 1/1] ethdev: don't consider device state when validating flows John Daley
2017-04-06 20:50   ` Thomas Monjalon
2017-04-06 22:41   ` [PATCH v2 0/1] fix flow validate comments John Daley
2017-04-06 22:41     ` [PATCH v2 1/1] ethdev: " John Daley
2017-04-07  0:23       ` [PATCH v3] " John Daley
2017-04-11 10:01         ` Adrien Mazarguil
2017-04-20 18:49         ` John Daley [this message]
2017-04-21  8:11           ` [PATCH v4] doc: " Adrien Mazarguil
2017-04-21  8:42             ` Thomas Monjalon
2017-03-24  9:46 ` [PATCH 0/1] proposed minor change in rte_flow_validate semantics Adrien Mazarguil
2017-03-24 17:23   ` John Daley (johndale)

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=20170420184933.27450-1-johndale@cisco.com \
    --to=johndale@cisco.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=dev@dpdk.org \
    --cc=john.mcnamara@intel.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
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.