<html data-lt-installed="true"><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">On 6/2/22 02:20, Andrew Rybchenko
wrote:<br>
</div>
<blockquote type="cite" cite="mid:9dfcaec4-c4af-2e64-909d-51ca0f8da554@oktetlabs.ru">Summary
must not be a statement. May be:
<br>
ethdev: add strict queue to pre-configuration flow hints
<br>
</blockquote>
Ok, I'll change to this.<br>
<blockquote type="cite" cite="mid:9dfcaec4-c4af-2e64-909d-51ca0f8da554@oktetlabs.ru">
<br>
On 6/1/22 10:39, Xiaoyu Min wrote:
<br>
<blockquote type="cite">The data-path focused flow rule management
can manage flow rules in more
<br>
optimized way than traditional one by using hints provided by
<br>
application in initialization phase.
<br>
<br>
In addition to the current hints we have in port attr, more
hints could
<br>
be provided by application about its behaviour.
<br>
<br>
One example is how the application do with the same flow rule ?
<br>
A. create/destroy flow on same queue but query flow on different
queue
<br>
or queue-less way (i.e, counter query)
<br>
B. All flow operations will be exactly on the same queue, by
which PMD
<br>
could be in more optimized way then A because resource could
be
<br>
isolated and access based on queue, without lock, for
example.
<br>
<br>
This patch add flag about above situation and could be extended
to cover
<br>
more situations.
<br>
<br>
Signed-off-by: Xiaoyu Min <a class="moz-txt-link-rfc2396E" href="mailto:jackmin@nvidia.com"><jackmin@nvidia.com></a>
<br>
---
<br>
lib/ethdev/rte_flow.h | 11 +++++++++++
<br>
1 file changed, 11 insertions(+)
<br>
<br>
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
<br>
index d8827dd184..38439fcd1d 100644
<br>
--- a/lib/ethdev/rte_flow.h
<br>
+++ b/lib/ethdev/rte_flow.h
<br>
@@ -4948,6 +4948,12 @@ rte_flow_info_get(uint16_t port_id,
<br>
struct rte_flow_queue_info *queue_info,
<br>
struct rte_flow_error *error);
<br>
+/**
<br>
+ * Indicate all operations for a given flow rule will
_strictly_ happen
<br>
+ * on the same queue (create/destroy/query/update).
<br>
+ */
<br>
+#define RTE_FLOW_PORT_FLAG_STRICT_QUEUE RTE_BIT32(0)
<br>
+
<br>
/**
<br>
* @warning
<br>
* @b EXPERIMENTAL: this API may change without prior notice.
<br>
@@ -4972,6 +4978,11 @@ struct rte_flow_port_attr {
<br>
* @see RTE_FLOW_ACTION_TYPE_METER
<br>
*/
<br>
uint32_t nb_meters;
<br>
+ /**
<br>
+ * Port flags.
<br>
+ * @see RTE_FLOW_PORT_FLAG_STRICT_QUEUE
<br>
</blockquote>
<br>
I'm not sure that it is a good idea to list flags here.
<br>
If so, it will be required to add all future flags here.
<br>
</blockquote>
Yes, it will become a lot later on.<br>
<blockquote type="cite" cite="mid:9dfcaec4-c4af-2e64-909d-51ca0f8da554@oktetlabs.ru">So,
may be just "Port flags (RTE_FLOW_PORT_FLAG_*)"
<br>
</blockquote>
Sure.<br>
<blockquote type="cite" cite="mid:9dfcaec4-c4af-2e64-909d-51ca0f8da554@oktetlabs.ru">
<br>
<blockquote type="cite">+ */
<br>
+ uint32_t flags;
<br>
};
<br>
/**
<br>
</blockquote>
<br>
</blockquote>
</body>
<lt-container></lt-container>
</html>