queue-based flow aged report

-----Original Message-----
From: Jack Min <[email protected]>
Sent: Thursday, April 7, 2022 8:31 AM
Subject: [RFC 1/2] ethdev: port flags for pre-configuration flow hints

The data-path focused flow rule management can manage flow rules in more optimized way then tranditional one by using hits provided by application in initialization phase.

In addition to the current hints we have in port attr, more hints could be proivded by application about it's behaviour.

One example is how the application do with the same flow:
A. create/destroy flow on same queue but query flow on different queue
or queue-less way (i.e, counter query)
B. All flow operations will be exactly on the same queue, by which PMD
could be in more optimized way then A because resource could be isolated and access based on queue, without lock for example.

This patch add flag about above situation and could be extanded to cover more situations.

Signed-off-by Xiaoyu Min <[email protected]>

---
 lib/ethdev/rte_flow.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

lib/ethdev/rte_flow.h +11 -0

index d8827dd184..578dd837f5 100644
@@ -4875,6 +4875,17 @@ rte_flow_flex_item_release(uint16_t port_id,
 			   const struct rte_flow_item_flex_handle *handle,
 			   struct rte_flow_error *error);
 
+/**
+ * The flags of rte flow port
+ */
+enum rte_flow_port_flag {
+	/**
+	 * All flow operations for one specified flow will _strictlly_ happen
+	 * on the same queue (create/destroy/query/update).
+	 */
+	RTE_FLOW_PORT_FLAG_STRICT_QUEUE = RTE_BIT32(0),
+};
+
 /**
  * @warning
  * @b EXPERIMENTAL: this API may change without prior notice.

lib/ethdev/rte_flow.h +0 -1

 };
 
 /**
--

2.35.1

Hi Jack,

Quoted 53 lines

-----Original Message-----
From: Jack Min<[email protected]>
Sent: Thursday, April 7, 2022 8:31 AM
Subject: [RFC 1/2] ethdev: port flags for pre-configuration flow hints

The data-path focused flow rule management can manage flow rules in more optimized way then tranditional one by using hits provided by application in initialization phase.

In addition to the current hints we have in port attr, more hints could be proivded by application about it's behaviour.

One example is how the application do with the same flow:
A. create/destroy flow on same queue but query flow on different queue
or queue-less way (i.e, counter query)
B. All flow operations will be exactly on the same queue, by which PMD
could be in more optimized way then A because resource could be isolated and access based on queue, without lock for example.

This patch add flag about above situation and could be extanded to cover more situations.

Signed-off-by Xiaoyu Min<[email protected]>

---
  lib/ethdev/rte_flow.h | 16 ++++++++++++++++
  1 file changed, 16 insertions(+)

lib/ethdev/rte_flow.h +11 -0

index d8827dd184..578dd837f5 100644
@@ -4875,6 +4875,17 @@ rte_flow_flex_item_release(uint16_t port_id,
  			   const struct rte_flow_item_flex_handle *handle,
  			   struct rte_flow_error *error);
 
+/**
+ * The flags of rte flow port
+ */
+enum rte_flow_port_flag {
+	/**
+	 * All flow operations for one specified flow will _strictlly_ happen
+	 * on the same queue (create/destroy/query/update).
+	 */
+	RTE_FLOW_PORT_FLAG_STRICT_QUEUE = RTE_BIT32(0),
+};
+
  /**
   * @warning
   * @b EXPERIMENTAL: this API may change without prior notice.

@@ -4972,6 +4983,11 @@ struct rte_flow_port_attr {
  	 * @see RTE_FLOW_ACTION_TYPE_METER
  	 */

lib/ethdev/rte_flow.h struct rte_flow_port_attr { · line 4990

Quoted 6 lines

lib/ethdev/rte_flow.h +5 -0

  	uint32_t nb_meters;
+	/**
+	 * Port flags.
+	 * @see enum rte_flow_port_flag
+	 */
+	enum rte_flow_port_flag flags;

Why the use of enum and not flags?
I guess there will be more flags in future, and those flags will not be related to the strict queue.

Quoted 5 lines

lib/ethdev/rte_flow.h +0 -1

  };
 
  /**
--

2.35.1

lib/ethdev/rte_flow.h struct rte_flow_port_attr { · line 4990

Quoted 10 lines · On Thu, 7 Apr 2022 13:30:46 +0800 Xiaoyu Min<[email protected]> wrote:

* @b EXPERIMENTAL: this API may change without prior notice.

lib/ethdev/rte_flow.h +5 -0

@@ -4972,6 +4983,11 @@ struct rte_flow_port_attr {
  	 * @see RTE_FLOW_ACTION_TYPE_METER
  	 */
  	uint32_t nb_meters;
+	/**
+	 * Port flags.
+	 * @see enum rte_flow_port_flag
+	 */
+	enum rte_flow_port_flag flags;

This would have to wait until 22.11 because it is ABI breakage. Also, how would this work with old users of API?

The data-path focused flow rule management can manage flow rules in more optimized way then tranditional one by using hits provided by

application in initialization phase.

In addition to the current hints we have in port attr, more hints could be proivded by application about it's behaviour.

One example is how the application do with the same flow:

A. create/destroy flow on same queue but query flow on different queue
or queue-less way (i.e, counter query)
B. All flow operations will be exactly on the same queue, by which PMD
could be in more optimized way then A because resource could be isolated and access based on queue, without lock for example.

This patch add flag about above situation and could be extanded to cover

We were waiting for a v2 of this patch.

More comments below.

07/04/2022 07:30, Xiaoyu Min:

Quoted 2 lines

The data-path focused flow rule management can manage flow rules in more optimized way then tranditional one by using hits provided by

hits -> hints

Quoted 4 lines

application in initialization phase.

In addition to the current hints we have in port attr, more hints could be proivded by application about it's behaviour.

it's -> its

Quoted 1 line

One example is how the application do with the same flow:

flow -> flow rule ?

Quoted 7 lines

A. create/destroy flow on same queue but query flow on different queue
or queue-less way (i.e, counter query)
B. All flow operations will be exactly on the same queue, by which PMD
could be in more optimized way then A because resource could be isolated and access based on queue, without lock for example.

This patch add flag about above situation and could be extanded to cover

extended

lib/ethdev/rte_flow.h rte_flow_flex_item_release(uint16_t port_id, · line 4881

Quoted 8 lines

more situations.

Signed-off-by Xiaoyu Min<[email protected]>

---

lib/ethdev/rte_flow.h +4 -0

+/**
+ * The flags of rte flow port
+ */
+enum rte_flow_port_flag {

Don't use enum for bit flags.

Review

Quoted 2 lines

(quoted diff) +2 -0

+	/**
+	 * All flow operations for one specified flow will _strictlly_ happen

I guess you mean "for a given flow rule"

strictlly -> _strictly_

When application use queue-based flow management and operate the same flow on the same queue, e.g create/destroy/query, API for querying aged flows should also with queue id parameter just like other queue-based flow APIs.

By this way, PMD can work in more optimized way since resources are isolated by queue and needn't synchronize.

If application do use queue-based flow management but configure port without RTE_FLOW_PORT_FLAG_STRICT_QUEUE, which means application operate the same flow on different queues, the queue id parameter will be ignored.

Signed-off-by Xiaoyu Min <[email protected]>

---
 doc/guides/prog_guide/rte_flow.rst |  4 +++
 lib/ethdev/rte_flow.h              | 44 ++++++++++++++++++++++++++++++
 lib/ethdev/rte_flow_driver.h       |  7 +++++
 3 files changed, 55 insertions(+)

doc/guides/prog_guide/rte_flow.rst +4 -0

index 588914b231..d540152d74 100644
@@ -2963,6 +2963,10 @@ Set ageing timeout configuration to a flow.
 Event RTE_ETH_EVENT_FLOW_AGED will be reported if
 timeout passed without any matching on the flow.
 
+If queue-based flow rule management is used, when this
+even is triggered, the ret_param is set to corresponding
+flow queue.
+
 .. _table_rte_flow_action_age:
 
 .. table:: AGE

lib/ethdev/rte_flow.h +0 -0

index 578dd837f5..9394fb6965 100644

07/04/2022 07:30, Xiaoyu Min:

Quoted 4 lines

When application use queue-based flow management and operate the same flow on the same queue, e.g create/destroy/query, API for querying aged flows should also with queue id parameter just like other queue-based flow APIs.

A verb is missing, I am not sure to understand.

Quoted 30 lines

By this way, PMD can work in more optimized way since resources are isolated by queue and needn't synchronize.

If application do use queue-based flow management but configure port without RTE_FLOW_PORT_FLAG_STRICT_QUEUE, which means application operate the same flow on different queues, the queue id parameter will be ignored.

Signed-off-by Xiaoyu Min<[email protected]>

---
  doc/guides/prog_guide/rte_flow.rst |  4 +++
  lib/ethdev/rte_flow.h              | 44 ++++++++++++++++++++++++++++++
  lib/ethdev/rte_flow_driver.h       |  7 +++++
  3 files changed, 55 insertions(+)

doc/guides/prog_guide/rte_flow.rst +4 -0

index 588914b231..d540152d74 100644
@@ -2963,6 +2963,10 @@ Set ageing timeout configuration to a flow.
  Event RTE_ETH_EVENT_FLOW_AGED will be reported if
  timeout passed without any matching on the flow.
 
+If queue-based flow rule management is used, when this
+even is triggered, the ret_param is set to corresponding
+flow queue.
+
  .. _table_rte_flow_action_age:
 

lib/ethdev/rte_flow.h struct rte_flow_action_queue { · line 2943

Quoted 12 lines

doc/guides/prog_guide/rte_flow.rst +0 -0

  .. table:: AGE

lib/ethdev/rte_flow.h +5 -0

index 578dd837f5..9394fb6965 100644
   * The flow context and the flow handle will be reported by the
   * rte_flow_get_aged_flows API.
+ *
+ * If queue-based flow rule management is used and port configured with
+ * flag RTE_FLOW_PORT_FLAG_STRICT_QUEUE, RTE_ETH_EVENT_FLOW_AGED event
+ * is triggered with ret_param set to the corresponding flow queue when
+ * a flow queue detects new aged-out flows.

Are you sure it is a good idea to use ret_param for such data?

ret_param of an event is supposed to be used by the driver to get a confirmation from the application.

If the application needs extra info of an event,
it is better to do a separate query like rte_flow_get_aged_flows().

Quoted 7 lines

07/04/2022 07:30, Xiaoyu Min:

Quoted 4 lines

+ * If queue-based flow rule management is used and port configured with
+ * flag RTE_FLOW_PORT_FLAG_STRICT_QUEUE, RTE_ETH_EVENT_FLOW_AGED event
+ * is triggered with ret_param set to the corresponding flow queue when
+ * a flow queue detects new aged-out flows.

Are you sure it is a good idea to use ret_param for such data?

Well, it seems the only way to add queue information without add/change APIs.

Quoted 5 lines

ret_param of an event is supposed to be used by the driver to get a confirmation from the application.

If the application needs extra info of an event,
it is better to do a separate query like rte_flow_get_aged_flows().

Ok, since the *ret_param* is supposed to be used by driver, then the above approach is not a good idea.

So we need a new API, something like rte_flow_get_aged_event_queues(), which will return

all flow queues which has the aged flows, right?

-----Original Message-----
From: Jack Min <[email protected]>
Sent: Wednesday, June 1, 2022 10:39 AM
Subject: [RFC v2 1/2] ethdev: port flags for pre-configuration flow hints

The data-path focused flow rule management can manage flow rules in more optimized way than traditional one by using hints provided by application in initialization phase.

In addition to the current hints we have in port attr, more hints could be provided by application about its behaviour.

One example is how the application do with the same flow rule ? A. create/destroy flow on same queue but query flow on different queue
or queue-less way (i.e, counter query)
B. All flow operations will be exactly on the same queue, by which PMD
could be in more optimized way then A because resource could be isolated and access based on queue, without lock, for example.

This patch add flag about above situation and could be extended to cover more situations.

Signed-off-by Xiaoyu Min <[email protected]>

---
 lib/ethdev/rte_flow.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

lib/ethdev/rte_flow.h +11 -1

index d8827dd184..38439fcd1d 100644
@@ -4948,6 +4948,12 @@ rte_flow_info_get(uint16_t port_id,
 		  struct rte_flow_queue_info *queue_info,
 		  struct rte_flow_error *error);
 
+/**
+ * Indicate all operations for a given flow rule will _strictly_ happen
+ * on the same queue (create/destroy/query/update).
+ */
+#define RTE_FLOW_PORT_FLAG_STRICT_QUEUE RTE_BIT32(0)
+
 /**
  * @warning
  * @b EXPERIMENTAL: this API may change without prior notice.

@@ -4972,6 +4978,11 @@ struct rte_flow_port_attr {
 	 * @see RTE_FLOW_ACTION_TYPE_METER
 	 */
 	uint32_t nb_meters;
+	/**
+	 * Port flags.
+	 * @see RTE_FLOW_PORT_FLAG_STRICT_QUEUE
+	 */
+	uint32_t flags;
 };
 
 /**
--

2.36.1

The data-path focused flow rule management can manage flow rules in more optimized way than traditional one by using hints provided by application in initialization phase.

In addition to the current hints we have in port attr, more hints could be provided by application about its behaviour.

One example is how the application do with the same flow rule ? A. create/destroy flow on same queue but query flow on different queue
or queue-less way (i.e, counter query)
B. All flow operations will be exactly on the same queue, by which PMD
could be in more optimized way then A because resource could be isolated and access based on queue, without lock, for example.

This patch add flag about above situation and could be extended to cover more situations.

Signed-off-by Xiaoyu Min <[email protected]>

---
  lib/ethdev/rte_flow.h | 11 +++++++++++
  1 file changed, 11 insertions(+)

lib/ethdev/rte_flow.h +6 -0

index d8827dd184..38439fcd1d 100644
@@ -4948,6 +4948,12 @@ rte_flow_info_get(uint16_t port_id,
  		  struct rte_flow_queue_info *queue_info,
  		  struct rte_flow_error *error);
 
+/**
+ * Indicate all operations for a given flow rule will _strictly_ happen
+ * on the same queue (create/destroy/query/update).
+ */
+#define RTE_FLOW_PORT_FLAG_STRICT_QUEUE RTE_BIT32(0)
+
  /**
   * @warning
   * @b EXPERIMENTAL: this API may change without prior notice.

lib/ethdev/rte_flow.h +2 -0

+	 */
+	uint32_t flags;
  };
 
  /**

-----Original Message-----
From: Andrew Rybchenko <[email protected]>
Sent: Wednesday, June 1, 2022 9:21 PM
Subject: Re: [RFC v2 1/2] ethdev: port flags for pre-configuration flow hints

Summary must not be a statement. May be:
ethdev: add strict queue to pre-configuration flow hints

Quoted 42 lines · Xiaoyu Min

The data-path focused flow rule management can manage flow rules in more optimized way than traditional one by using hints provided by application in initialization phase.

In addition to the current hints we have in port attr, more hints could be provided by application about its behaviour.

One example is how the application do with the same flow rule ? A. create/destroy flow on same queue but query flow on different queue
or queue-less way (i.e, counter query)
B. All flow operations will be exactly on the same queue, by which PMD
could be in more optimized way then A because resource could be isolated and access based on queue, without lock, for example.

This patch add flag about above situation and could be extended to cover more situations.

Signed-off-by Xiaoyu Min <[email protected]>

---
  lib/ethdev/rte_flow.h | 11 +++++++++++
  1 file changed, 11 insertions(+)

lib/ethdev/rte_flow.h +6 -0

index d8827dd184..38439fcd1d 100644
@@ -4948,6 +4948,12 @@ rte_flow_info_get(uint16_t port_id,
  		  struct rte_flow_queue_info *queue_info,
  		  struct rte_flow_error *error);
 
+/**
+ * Indicate all operations for a given flow rule will _strictly_ happen
+ * on the same queue (create/destroy/query/update).
+ */
+#define RTE_FLOW_PORT_FLAG_STRICT_QUEUE RTE_BIT32(0)
+
  /**
   * @warning
   * @b EXPERIMENTAL: this API may change without prior notice.

@@ -4972,6 +4978,11 @@ struct rte_flow_port_attr {
  	 * @see RTE_FLOW_ACTION_TYPE_METER
  	 */

lib/ethdev/rte_flow.h struct rte_flow_port_attr { · line 4983

Quoted 4 lines

lib/ethdev/rte_flow.h +3 -0

  	uint32_t nb_meters;
+	/**
+	 * Port flags.
+	 * @see RTE_FLOW_PORT_FLAG_STRICT_QUEUE

I'm not sure that it is a good idea to list flags here. If so, it will be required to add all future flags here. So, may be just "Port flags (RTE_FLOW_PORT_FLAG_*)"

Quoted 5 lines

lib/ethdev/rte_flow.h +2 -0

+	 */
+	uint32_t flags;
  };
 
  /**

Summary must not be a statement. May be:
ethdev: add strict queue to pre-configuration flow hints

Quoted 40 lines

The data-path focused flow rule management can manage flow rules in more optimized way than traditional one by using hints provided by application in initialization phase.

In addition to the current hints we have in port attr, more hints could be provided by application about its behaviour.

One example is how the application do with the same flow rule ? A. create/destroy flow on same queue but query flow on different queue or queue-less way (i.e, counter query)
B. All flow operations will be exactly on the same queue, by which PMD could be in more optimized way then A because resource could be isolated and access based on queue, without lock, for example.

This patch add flag about above situation and could be extended to cover more situations.

Signed-off-by Xiaoyu Min <[email protected]>

---
  lib/ethdev/rte_flow.h | 11 +++++++++++

  1 file changed, 11 insertions(+)

lib/ethdev/rte_flow.h +0 -0

index d8827dd184..38439fcd1d 100644
@@ -4948,6 +4948,12 @@ rte_flow_info_get(uint16_t port_id,
             struct rte_flow_queue_info *queue_info,
             struct rte_flow_error *error);

  +/**
+ * Indicate all operations for a given flow rule will _strictly_ happen
+ * on the same queue (create/destroy/query/update).
+ */

lib/ethdev/rte_flow.h +2 -0

+#define RTE_FLOW_PORT_FLAG_STRICT_QUEUE RTE_BIT32(0)
+

  /**
   * @warning
   * @b EXPERIMENTAL: this API may change without prior notice.

lib/ethdev/rte_flow.h +0 -0

@@ -4972,6 +4978,11 @@ struct rte_flow_port_attr {
        * @see RTE_FLOW_ACTION_TYPE_METER

lib/ethdev/rte_flow.h struct rte_flow_port_attr { · line 4983

Quoted 5 lines

lib/ethdev/rte_flow.h +3 -0

        */
       uint32_t nb_meters;
+    /**
+     * Port flags.
+     * @see RTE_FLOW_PORT_FLAG_STRICT_QUEUE

I'm not sure that it is a good idea to list flags here. If so, it will be required to add all future flags here.

So, may be just "Port flags (RTE_FLOW_PORT_FLAG_*)"

Quoted 5 lines

lib/ethdev/rte_flow.h +2 -0

+     */
+    uint32_t flags;
   };
     /**

When application use queue-based flow rule management and operate the same flow rule on the same queue, e.g create/destroy/query, API of querying aged flow rules should also have queue id parameter just like other queue-based flow APIs.

By this way, PMD can work in more optimized way since resources are isolated by queue and needn't synchronize.

If application do use queue-based flow management but configure port without RTE_FLOW_PORT_FLAG_STRICT_QUEUE, which means application operate a given flow rule on different queues, the queue id parameter will be ignored.

In addition to the above change, another new API is added which help the application get information about which queues have aged out flows after RTE_ETH_EVENT_FLOW_AGED event received. The queried queue id can be used in the above queue based query aged flows API.

Signed-off-by Xiaoyu Min <[email protected]>

---
  lib/ethdev/rte_flow.h        | 82 ++++++++++++++++++++++++++++++++++++
  lib/ethdev/rte_flow_driver.h | 13 ++++++
  2 files changed, 95 insertions(+)

lib/ethdev/rte_flow.h +19 -0

index 38439fcd1d..a12becfe3b 100644
@@ -2810,6 +2810,7 @@ enum rte_flow_action_type {
  	 * See function rte_flow_get_aged_flows
  	 * see enum RTE_ETH_EVENT_FLOW_AGED
  	 * See struct rte_flow_query_age
+	 * See function rte_flow_get_q_aged_flows
  	 */
  	RTE_FLOW_ACTION_TYPE_AGE,
 

@@ -5624,6 +5625,87 @@ rte_flow_async_action_handle_update(uint16_t port_id,
  		const void *update,
  		void *user_data,
  		struct rte_flow_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get flow queues which have aged out flows on a given port.
+ *
+ * The application can use this function to query which queues have aged out flows after
+ * a RTE_ETH_EVENT_FLOW_AGED event is received so the returned queue id can be used to
+ * get aged out flows on this given queue by call rte_flow_get_q_aged_flows.
+ *
+ * This function can be called from the event callback or synchronously regardless of the event.
+ *
+ * @param port_id
+ *   Port identifier of Ethernet device.
+ * @param[in, out] queue_id
+ *   Array of queue id that will be set.
+ * @param[in] nb_queue_id

lib/ethdev/rte_flow.h +53 -0

+ *
+ * @see rte_flow_action_age
+ * @see RTE_ETH_EVENT_FLOW_AGED
+ */
+
+__rte_experimental
+int
+rte_flow_get_aged_queues(uint16_t port_id, uint32_t queue_id[], uint32_t nb_queue_id,
+			 struct rte_flow_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get aged-out flows of a given port on the given flow queue.
+ *
+ * RTE_ETH_EVENT_FLOW_AGED event will be triggered at least one new aged out flow was
+ * detected on any flow queue after the last call to rte_flow_get_q_aged_flows.
+ *
+ * The application can use rte_flow_get_aged_queues to query which queues have aged
+ * out flows after RTE_ETH_EVEN_FLOW_AGED event.
+ *
+ * If application configure port attribute without RTE_FLOW_PORT_FLAG_STRICT_QUEUE
+ * the @p queue_id will be ignored.
+ * This function can be called to get the aged flows asynchronously from the
+ * event callback or synchronously regardless the event.
+ *
+ * @param port_id
+ *   Port identifier of Ethernet device.
+ * @param queue_id
+ *   Flow queue to query. Ignored when RTE_FLOW_PORT_FLAG_STRICT_QUEUE not set.
+ * @param[in, out] contexts
+ *   The address of an array of pointers to the aged-out flows contexts.
+ * @param[in] nb_contexts
+ *   The length of context array pointers.
+ * @param[out] error
+ *   Perform verbose error reporting if not NULL. Initialized in case of
+ *   error only.
+ *
+ * @return
+ *   if nb_contexts is 0, return the amount of all aged contexts.
+ *   if nb_contexts is not 0 , return the amount of aged flows reported
+ *   in the context array, otherwise negative errno value.
+ *
+ * @see rte_flow_action_age
+ * @see RTE_ETH_EVENT_FLOW_AGED
+ * @see rte_flow_port_flag
+ */
+
+__rte_experimental
+int
+rte_flow_get_q_aged_flows(uint16_t port_id, uint32_t queue_id, void **contexts,
+			  uint32_t nb_contexts, struct rte_flow_error *error);
  #ifdef __cplusplus
  }
  #endif

lib/ethdev/rte_flow_driver.h +13 -0

index 2bff732d6a..b665170bf4 100644
@@ -260,6 +260,19 @@ struct rte_flow_ops {
  		 const void *update,
  		 void *user_data,
  		 struct rte_flow_error *error);
+	/** See rte_flow_get_aged_queues() */
+	int (*get_aged_queues)
+		(uint16_t port_id,
+		 uint32_t queue_id[],
+		 uint32_t nb_queue_id,
+		 struct rte_flow_error *error);
+	/** See rte_flow_get_q_aged_flows() */
+	int (*get_q_aged_flows)
+		(uint16_t port_id,
+		 uint32_t queue_id,
+		 void **contexts,
+		 uint32_t nb_contexts,
+		 struct rte_flow_error *error);
  };
 
  /**

-----Original Message-----
From: Andrew Rybchenko <[email protected]>
Sent: Wednesday, June 1, 2022 9:21 PM
Subject: Re: [RFC v2 2/2] ethdev: queue-based flow aged report

Again, summary must not be a statement.

Quoted 66 lines · Xiaoyu Min

When application use queue-based flow rule management and operate the same flow rule on the same queue, e.g create/destroy/query, API of querying aged flow rules should also have queue id parameter just like other queue-based flow APIs.

By this way, PMD can work in more optimized way since resources are isolated by queue and needn't synchronize.

If application do use queue-based flow management but configure port without RTE_FLOW_PORT_FLAG_STRICT_QUEUE, which means application operate a given flow rule on different queues, the queue id parameter will be ignored.

In addition to the above change, another new API is added which help the application get information about which queues have aged out flows after RTE_ETH_EVENT_FLOW_AGED event received. The queried queue id can be used in the above queue based query aged flows API.

Signed-off-by Xiaoyu Min <[email protected]>

---
  lib/ethdev/rte_flow.h        | 82 ++++++++++++++++++++++++++++++++++++
  lib/ethdev/rte_flow_driver.h | 13 ++++++
  2 files changed, 95 insertions(+)

lib/ethdev/rte_flow.h +27 -0

index 38439fcd1d..a12becfe3b 100644
@@ -2810,6 +2810,7 @@ enum rte_flow_action_type {
  	 * See function rte_flow_get_aged_flows
  	 * see enum RTE_ETH_EVENT_FLOW_AGED
  	 * See struct rte_flow_query_age
+	 * See function rte_flow_get_q_aged_flows
  	 */
  	RTE_FLOW_ACTION_TYPE_AGE,
 

@@ -5624,6 +5625,87 @@ rte_flow_async_action_handle_update(uint16_t port_id,
  		const void *update,
  		void *user_data,
  		struct rte_flow_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get flow queues which have aged out flows on a given port.
+ *
+ * The application can use this function to query which queues have aged out flows after
+ * a RTE_ETH_EVENT_FLOW_AGED event is received so the returned queue id can be used to
+ * get aged out flows on this given queue by call rte_flow_get_q_aged_flows.
+ *
+ * This function can be called from the event callback or synchronously regardless of the event.
+ *
+ * @param port_id
+ *   Port identifier of Ethernet device.
+ * @param[in, out] queue_id
+ *   Array of queue id that will be set.
+ * @param[in] nb_queue_id
+ *   Maximum number of the queue id that can be returned.
+ *   This value should be equal to the size of the queue_id array.
+ * @param[out] error
+ *   Perform verbose error reporting if not NULL. Initialized in case of
+ *   error only.
+ *
+ * @return
+ *   if nb_queue_id is 0, return the amount of all queues which have aged out flows.

lib/ethdev/rte_flow.h rte_flow_async_action_handle_update(uint16_t port_id, · line 5655

Quoted 2 lines

lib/ethdev/rte_flow.h +2 -0

+ *   if nb_queue_id is not 0 , return the amount of queues which have aged out flows
+ *   reported in the queue_id array, otherwise negative errno value.

I'm sorry, but it is unclear for me what happens if provided array is insufficient to return all queues. IMHO, we still should provide as much as we can. The question is how to report that we have more queues. It looks like the only sensible way is to return value greater than nb_queue_id.

Quoted 80 lines

lib/ethdev/rte_flow.h +53 -0

+ *
+ * @see rte_flow_action_age
+ * @see RTE_ETH_EVENT_FLOW_AGED
+ */
+
+__rte_experimental
+int
+rte_flow_get_aged_queues(uint16_t port_id, uint32_t queue_id[], uint32_t nb_queue_id,
+			 struct rte_flow_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get aged-out flows of a given port on the given flow queue.
+ *
+ * RTE_ETH_EVENT_FLOW_AGED event will be triggered at least one new aged out flow was
+ * detected on any flow queue after the last call to rte_flow_get_q_aged_flows.
+ *
+ * The application can use rte_flow_get_aged_queues to query which queues have aged
+ * out flows after RTE_ETH_EVEN_FLOW_AGED event.
+ *
+ * If application configure port attribute without RTE_FLOW_PORT_FLAG_STRICT_QUEUE
+ * the @p queue_id will be ignored.
+ * This function can be called to get the aged flows asynchronously from the
+ * event callback or synchronously regardless the event.
+ *
+ * @param port_id
+ *   Port identifier of Ethernet device.
+ * @param queue_id
+ *   Flow queue to query. Ignored when RTE_FLOW_PORT_FLAG_STRICT_QUEUE not set.
+ * @param[in, out] contexts
+ *   The address of an array of pointers to the aged-out flows contexts.
+ * @param[in] nb_contexts
+ *   The length of context array pointers.
+ * @param[out] error
+ *   Perform verbose error reporting if not NULL. Initialized in case of
+ *   error only.
+ *
+ * @return
+ *   if nb_contexts is 0, return the amount of all aged contexts.
+ *   if nb_contexts is not 0 , return the amount of aged flows reported
+ *   in the context array, otherwise negative errno value.
+ *
+ * @see rte_flow_action_age
+ * @see RTE_ETH_EVENT_FLOW_AGED
+ * @see rte_flow_port_flag
+ */
+
+__rte_experimental
+int
+rte_flow_get_q_aged_flows(uint16_t port_id, uint32_t queue_id, void **contexts,
+			  uint32_t nb_contexts, struct rte_flow_error *error);
  #ifdef __cplusplus
  }
  #endif

lib/ethdev/rte_flow_driver.h +13 -0

index 2bff732d6a..b665170bf4 100644
@@ -260,6 +260,19 @@ struct rte_flow_ops {
  		 const void *update,
  		 void *user_data,
  		 struct rte_flow_error *error);
+	/** See rte_flow_get_aged_queues() */
+	int (*get_aged_queues)
+		(uint16_t port_id,
+		 uint32_t queue_id[],
+		 uint32_t nb_queue_id,
+		 struct rte_flow_error *error);
+	/** See rte_flow_get_q_aged_flows() */
+	int (*get_q_aged_flows)
+		(uint16_t port_id,
+		 uint32_t queue_id,
+		 void **contexts,
+		 uint32_t nb_contexts,
+		 struct rte_flow_error *error);
  };
 
  /**

Hi,

Quoted 74 lines

-----Original Message-----
From: Andrew Rybchenko<[email protected]>
Sent: Wednesday, June 1, 2022 9:21 PM
Subject: Re: [RFC v2 2/2] ethdev: queue-based flow aged report

Again, summary must not be a statement.

Quoted 65 lines · Xiaoyu Min

When application use queue-based flow rule management and operate the same flow rule on the same queue, e.g create/destroy/query, API of querying aged flow rules should also have queue id parameter just like other queue-based flow APIs.

By this way, PMD can work in more optimized way since resources are isolated by queue and needn't synchronize.

If application do use queue-based flow management but configure port without RTE_FLOW_PORT_FLAG_STRICT_QUEUE, which means application operate a given flow rule on different queues, the queue id parameter will be ignored.

In addition to the above change, another new API is added which help the application get information about which queues have aged out flows after RTE_ETH_EVENT_FLOW_AGED event received. The queried queue id can be used in the above queue based query aged flows API.

Signed-off-by Xiaoyu Min<[email protected]>

---
   lib/ethdev/rte_flow.h        | 82 ++++++++++++++++++++++++++++++++++++
   lib/ethdev/rte_flow_driver.h | 13 ++++++
   2 files changed, 95 insertions(+)

lib/ethdev/rte_flow.h +26 -0

index 38439fcd1d..a12becfe3b 100644
@@ -2810,6 +2810,7 @@ enum rte_flow_action_type {
   	 * See function rte_flow_get_aged_flows
   	 * see enum RTE_ETH_EVENT_FLOW_AGED
   	 * See struct rte_flow_query_age
+	 * See function rte_flow_get_q_aged_flows
   	 */
   	RTE_FLOW_ACTION_TYPE_AGE,
 

@@ -5624,6 +5625,87 @@ rte_flow_async_action_handle_update(uint16_t port_id,
   		const void *update,
   		void *user_data,
   		struct rte_flow_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get flow queues which have aged out flows on a given port.
+ *
+ * The application can use this function to query which queues have aged out flows after
+ * a RTE_ETH_EVENT_FLOW_AGED event is received so the returned queue id can be used to
+ * get aged out flows on this given queue by call rte_flow_get_q_aged_flows.
+ *
+ * This function can be called from the event callback or synchronously regardless of the event.
+ *
+ * @param port_id
+ *   Port identifier of Ethernet device.
+ * @param[in, out] queue_id
+ *   Array of queue id that will be set.
+ * @param[in] nb_queue_id
+ *   Maximum number of the queue id that can be returned.
+ *   This value should be equal to the size of the queue_id array.
+ * @param[out] error
+ *   Perform verbose error reporting if not NULL. Initialized in case of
+ *   error only.
+ *
+ * @return

Quoted 9 lines

lib/ethdev/rte_flow.h rte_flow_async_action_handle_update(uint16_t port_id, · line 5655

Quoted 3 lines

lib/ethdev/rte_flow.h +3 -0

+ *   if nb_queue_id is 0, return the amount of all queues which have aged out flows.
+ *   if nb_queue_id is not 0 , return the amount of queues which have aged out flows
+ *   reported in the queue_id array, otherwise negative errno value.

I'm sorry, but it is unclear for me what happens if provided array is insufficient to return all queues. IMHO, we still should provide as much as we can. The question is how to report that we have more queues. It looks like the only sensible way is to return value greater than nb_queue_id.

I think that just like any other function, this function should return the max based on the requested number. Returning bigger number may result in out of buf issues, or require extra validation step from application. In addition as far as I can see the common practice in DPDK is to return the requested number.

I have other concern with this function, from my understanding this function will be called on the service thread that handels the aging event, after calling this function the application still needs to propagate the event to the correct threads.
I think it will be better if the event itself will hold which queue triggered the aging. Or even better to get the

notification on the correct thread. (I know it is much more complicated but maybe it is worth the effort, since this can be used for other cases)

Quoted 81 lines

Quoted 81 lines

lib/ethdev/rte_flow.h +53 -0

+ *
+ * @see rte_flow_action_age
+ * @see RTE_ETH_EVENT_FLOW_AGED
+ */
+
+__rte_experimental
+int
+rte_flow_get_aged_queues(uint16_t port_id, uint32_t queue_id[], uint32_t nb_queue_id,
+			 struct rte_flow_error *error);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get aged-out flows of a given port on the given flow queue.
+ *
+ * RTE_ETH_EVENT_FLOW_AGED event will be triggered at least one new aged out flow was
+ * detected on any flow queue after the last call to rte_flow_get_q_aged_flows.
+ *
+ * The application can use rte_flow_get_aged_queues to query which queues have aged
+ * out flows after RTE_ETH_EVEN_FLOW_AGED event.
+ *
+ * If application configure port attribute without RTE_FLOW_PORT_FLAG_STRICT_QUEUE
+ * the @p queue_id will be ignored.
+ * This function can be called to get the aged flows asynchronously from the
+ * event callback or synchronously regardless the event.
+ *
+ * @param port_id
+ *   Port identifier of Ethernet device.
+ * @param queue_id
+ *   Flow queue to query. Ignored when RTE_FLOW_PORT_FLAG_STRICT_QUEUE not set.
+ * @param[in, out] contexts
+ *   The address of an array of pointers to the aged-out flows contexts.
+ * @param[in] nb_contexts
+ *   The length of context array pointers.
+ * @param[out] error
+ *   Perform verbose error reporting if not NULL. Initialized in case of
+ *   error only.
+ *
+ * @return
+ *   if nb_contexts is 0, return the amount of all aged contexts.
+ *   if nb_contexts is not 0 , return the amount of aged flows reported
+ *   in the context array, otherwise negative errno value.
+ *
+ * @see rte_flow_action_age
+ * @see RTE_ETH_EVENT_FLOW_AGED
+ * @see rte_flow_port_flag
+ */
+
+__rte_experimental
+int
+rte_flow_get_q_aged_flows(uint16_t port_id, uint32_t queue_id, void **contexts,
+			  uint32_t nb_contexts, struct rte_flow_error *error);
   #ifdef __cplusplus
   }
   #endif

lib/ethdev/rte_flow_driver.h +13 -0

index 2bff732d6a..b665170bf4 100644
@@ -260,6 +260,19 @@ struct rte_flow_ops {
   		 const void *update,
   		 void *user_data,
   		 struct rte_flow_error *error);
+	/** See rte_flow_get_aged_queues() */
+	int (*get_aged_queues)
+		(uint16_t port_id,
+		 uint32_t queue_id[],
+		 uint32_t nb_queue_id,
+		 struct rte_flow_error *error);
+	/** See rte_flow_get_q_aged_flows() */
+	int (*get_q_aged_flows)
+		(uint16_t port_id,
+		 uint32_t queue_id,
+		 void **contexts,
+		 uint32_t nb_contexts,
+		 struct rte_flow_error *error);
   };
 
   /**

Again, summary must not be a statement.

Quoted 66 lines

When application use queue-based flow rule management and operate the same flow rule on the same queue, e.g create/destroy/query, API of querying aged flow rules should also have queue id parameter just like other queue-based flow APIs.

By this way, PMD can work in more optimized way since resources are isolated by queue and needn't synchronize.

If application do use queue-based flow management but configure port without RTE_FLOW_PORT_FLAG_STRICT_QUEUE, which means application operate a given flow rule on different queues, the queue id parameter will be ignored.

In addition to the above change, another new API is added which help the application get information about which queues have aged out flows after RTE_ETH_EVENT_FLOW_AGED event received. The queried queue id can be used in the above queue based query aged flows API.

Signed-off-by Xiaoyu Min <[email protected]>

---
  lib/ethdev/rte_flow.h        | 82 ++++++++++++++++++++++++++++++++++++ lib/ethdev/rte_flow_driver.h | 13 ++++++

  2 files changed, 95 insertions(+)

lib/ethdev/rte_flow.h +1 -0

index 38439fcd1d..a12becfe3b 100644
@@ -2810,6 +2810,7 @@ enum rte_flow_action_type {
        * See function rte_flow_get_aged_flows
        * see enum RTE_ETH_EVENT_FLOW_AGED
        * See struct rte_flow_query_age
+     * See function rte_flow_get_q_aged_flows
        */
       RTE_FLOW_ACTION_TYPE_AGE,
   @@ -5624,6 +5625,87 @@ rte_flow_async_action_handle_update(uint16_t port_id,

          const void *update,
          void *user_data,
          struct rte_flow_error *error);

lib/ethdev/rte_flow.h +8 -0

+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get flow queues which have aged out flows on a given port.
+ *
+ * The application can use this function to query which queues have 

aged out flows after
+ * a RTE_ETH_EVENT_FLOW_AGED event is received so the returned queue id can be used to
+ * get aged out flows on this given queue by call rte_flow_get_q_aged_flows.
+ *
+ * This function can be called from the event callback or synchronously regardless of the event.
+ *
+ * @param port_id
+ *   Port identifier of Ethernet device.
+ * @param[in, out] queue_id
+ *   Array of queue id that will be set.
+ * @param[in] nb_queue_id
+ *   Maximum number of the queue id that can be returned.
+ *   This value should be equal to the size of the queue_id array.
+ * @param[out] error
+ *   Perform verbose error reporting if not NULL. Initialized in case of

Quoted 8 lines

+ *   error only.
+ *
+ * @return
+ *   if nb_queue_id is 0, return the amount of all queues which have aged out flows.
+ *   if nb_queue_id is not 0 , return the amount of queues which have aged out flows
+ *   reported in the queue_id array, otherwise negative errno value.

I'm sorry, but it is unclear for me what happens if provided array is insufficient to return all queues. IMHO, we still should provide as much as we can. The question is how to report that we have more queues.
It looks like the only sensible way is to return value greater than
nb_queue_id.

Quoted 89 lines

+ *
+ * @see rte_flow_action_age
+ * @see RTE_ETH_EVENT_FLOW_AGED
+ */

lib/ethdev/rte_flow.h +4 -0

+
+__rte_experimental
+int
+rte_flow_get_aged_queues(uint16_t port_id, uint32_t queue_id[], 

uint32_t nb_queue_id,
+             struct rte_flow_error *error);

lib/ethdev/rte_flow.h +8 -0

+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Get aged-out flows of a given port on the given flow queue.
+ *
+ * RTE_ETH_EVENT_FLOW_AGED event will be triggered at least one new 

aged out flow was
+ * detected on any flow queue after the last call to rte_flow_get_q_aged_flows.
+ *
+ * The application can use rte_flow_get_aged_queues to query which queues have aged
+ * out flows after RTE_ETH_EVEN_FLOW_AGED event.
+ *
+ * If application configure port attribute without RTE_FLOW_PORT_FLAG_STRICT_QUEUE
+ * the @p queue_id will be ignored.
+ * This function can be called to get the aged flows asynchronously from the
+ * event callback or synchronously regardless the event.
+ *
+ * @param port_id
+ *   Port identifier of Ethernet device.
+ * @param queue_id
+ *   Flow queue to query. Ignored when RTE_FLOW_PORT_FLAG_STRICT_QUEUE not set.
+ * @param[in, out] contexts
+ *   The address of an array of pointers to the aged-out flows contexts.
+ * @param[in] nb_contexts
+ *   The length of context array pointers.
+ * @param[out] error
+ *   Perform verbose error reporting if not NULL. Initialized in case of
+ *   error only.
+ *
+ * @return
+ *   if nb_contexts is 0, return the amount of all aged contexts.
+ *   if nb_contexts is not 0 , return the amount of aged flows reported
+ *   in the context array, otherwise negative errno value.
+ *
+ * @see rte_flow_action_age
+ * @see RTE_ETH_EVENT_FLOW_AGED
+ * @see rte_flow_port_flag
+ */

lib/ethdev/rte_flow.h +4 -0

+
+__rte_experimental
+int
+rte_flow_get_q_aged_flows(uint16_t port_id, uint32_t queue_id, void 

**contexts,
+              uint32_t nb_contexts, struct rte_flow_error *error); #ifdef __cplusplus
  }
  #endif

lib/ethdev/rte_flow_driver.h +13 -0

index 2bff732d6a..b665170bf4 100644
@@ -260,6 +260,19 @@ struct rte_flow_ops {
            const void *update,
            void *user_data,
            struct rte_flow_error *error);
+    /** See rte_flow_get_aged_queues() */
+    int (*get_aged_queues)
+        (uint16_t port_id,
+         uint32_t queue_id[],
+         uint32_t nb_queue_id,
+         struct rte_flow_error *error);
+    /** See rte_flow_get_q_aged_flows() */
+    int (*get_q_aged_flows)
+        (uint16_t port_id,
+         uint32_t queue_id,
+         void **contexts,
+         uint32_t nb_contexts,
+         struct rte_flow_error *error);
   };
     /**