On 11/7/2020 5:30 PM, Matan Azrad wrote:
Hi Ferruh

From: Ferruh Yigit
On 11/5/2020 9:32 PM, Matan Azrad wrote:
When an age action becomes aged-out the rte_flow_get_aged_flows should
return the action context supplied by the configuration structure.

In case the age action created by the shared action API, the shared
action context of the Testpmd application was not set.

In addition, the application handler of the contexts returned by the
rte_flow_get_aged_flows API didn't consider the fact that the action
could be set by the shared action API and considered it as regular
flow context.

This caused a crash in Testpmd when the context is parsed.

This patch set context type in the flow and shared action context and
uses it to parse the aged-out contexts correctly.

Signed-off-by: Matan Azrad <ma...@nvidia.com>
Acked-by: Dekel Peled <dek...@nvidia.com>
---
   app/test-pmd/config.c  | 119 ++++++++++++++++++++++++++++++++++-------
--------
   app/test-pmd/testpmd.h |   5 +++
   2 files changed, 87 insertions(+), 37 deletions(-)

diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
755d1df..00a7dd1 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1763,6 +1763,33 @@ void port_flow_tunnel_create(portid_t port_id,
const struct tunnel_ops *ops)
       }
   }

+#define AGE_ACTION_TYPE_MASK 0x3u
+
+static void
+set_age_action_context(void **ctx, enum action_age_context_type type,
+void *obj) {
+     uintptr_t value = (uintptr_t)obj;
+
+     /*
+      * obj is allocated by malloc\calloc which must return an address
+      * aligned to 8.
+      * Use the last 2 bits for the age context type.
+      */
+     value |= (uintptr_t)type & AGE_ACTION_TYPE_MASK;
+     *ctx = (void *)value;

Thanks Matan, I think this is much clear. But I though the 'id' will be used, 
not
the pointer itself, like "uintptr_t value = id | (type * MASK)"
OR the address pointer and type seems error prone, although you comment
you rely on the alignment.

I understand your concern, that's why the context value management is wrapped 
well by dedicated functions for set and parse.
Also it's very optimized way for memory and time especially when we are talking 
about big scale(see below).

The testpmd usage also kind of sample usage for the applications, I am for not
suggesting this for the user applications.


Reserving the two bit of the 'id' reduces the usable 'id' to 30 bits, but it 
looks
still big enough, what do you think?


Yes, it is big enough.
The problem with the id is the latency to get the pointer from it.
Since both the flows and the shared actions are saved in a list we need to 
traverse all the list in order to get the pointer and the needed information.


Using 'id' was your idea.

OK, what about back to previous suggestion, adding a new data struct for both pointers and type? Your concern there was the memory consumption, yes although it will require more memory the amount is not unreasonable.

Reply via email to