[v2] app/testpmd: support age shared action context
Checks
Commit Message
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 <matan@nvidia.com>
Acked-by: Dekel Peled <dekelp@nvidia.com>
---
app/test-pmd/config.c | 119 ++++++++++++++++++++++++++++++++++---------------
app/test-pmd/testpmd.h | 5 +++
2 files changed, 87 insertions(+), 37 deletions(-)
Comments
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 <matan@nvidia.com>
> Acked-by: Dekel Peled <dekelp@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.
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?
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 <matan@nvidia.com>
> > Acked-by: Dekel Peled <dekelp@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.
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 <matan@nvidia.com>
>>> Acked-by: Dekel Peled <dekelp@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.
From: Ferruh Yigit
> 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 <matan@nvidia.com>
> >>> Acked-by: Dekel Peled <dekelp@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.
Yes, Now I suggest even better one 😊
>
> 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.
Think about big scale.
It is not only memory (malloc overhead + ~16B) but also time consuming(malloc).
If we have solution that no need malloc and can do things faster, why not to take it?
I don't see here a bug - malloc alignment is a known topic - it should be at least the size of the biggest primitive type.
Matan
On 11/9/2020 10:38 AM, Matan Azrad wrote:
>
>
> From: Ferruh Yigit
>> 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 <matan@nvidia.com>
>>>>> Acked-by: Dekel Peled <dekelp@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.
>
> Yes, Now I suggest even better one 😊
>
>>
>> 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.
>
> Think about big scale.
> It is not only memory (malloc overhead + ~16B) but also time consuming(malloc).
>
> If we have solution that no need malloc and can do things faster, why not to take it?
> I don't see here a bug - malloc alignment is a known topic - it should be at least the size of the biggest primitive type.
>
I can see there is a cost, either with malloc/free, or traverse the list to find
'id', but updating memory pointer that you will use later to carry more metadata
looks hack and error prone to me.
One can do these kind of tricks on their application, but for testpmd which is
for testing and reference I didn't like the idea.
Hi,
Ferruh and Matan,
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Monday, November 9, 2020 1:13 PM
> To: Matan Azrad <matan@nvidia.com>; Wenzhuo Lu <wenzhuo.lu@intel.com>;
> Beilei Xing <beilei.xing@intel.com>; Bernard Iremonger
> <bernard.iremonger@intel.com>; Ori Kam <orika@nvidia.com>
> Cc: dev@dpdk.org
> Subject: Re: [PATCH v2] app/testpmd: support age shared action context
>
> On 11/9/2020 10:38 AM, Matan Azrad wrote:
> >
> >
> > From: Ferruh Yigit
> >> 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 <matan@nvidia.com>
> >>>>> Acked-by: Dekel Peled <dekelp@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.
> >
> > Yes, Now I suggest even better one 😊
> >
> >>
> >> 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.
> >
> > Think about big scale.
> > It is not only memory (malloc overhead + ~16B) but also time
> consuming(malloc).
> >
> > If we have solution that no need malloc and can do things faster, why not to
> take it?
> > I don't see here a bug - malloc alignment is a known topic - it should be at
> least the size of the biggest primitive type.
> >
>
> I can see there is a cost, either with malloc/free, or traverse the list to find
> 'id', but updating memory pointer that you will use later to carry more
> metadata
> looks hack and error prone to me.
>
> One can do these kind of tricks on their application, but for testpmd which is
> for testing and reference I didn't like the idea.
I know I'm jumping a bit late, I have a different suggestion.
What about creating new struct
Struct context_type {
uint8_t type; /**< holds the type of the context can be enum. */
}
This struct should be added to both shared context and flow.
When adding context to the aging action we add the pointer to this struct.
Then when getting the context pointer we cast it to struct context_type,
get the value, and based on the type we use parentof function to get to the
pointer of the original structure.
The advantages:
1. Just adding one uint8_t to each struct. (not wasting space).
2. Very fast lookup since we just add if on the type and then
use parentof.
3. No major changes in structs.
4. Not an hack.
5. save extra allocation.
6. can be expended to support future types.
What do you think?
Best,
Ori
On 11/10/2020 8:30 AM, Ori Kam wrote:
> Hi,
> Ferruh and Matan,
>
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit@intel.com>
>> Sent: Monday, November 9, 2020 1:13 PM
>> To: Matan Azrad <matan@nvidia.com>; Wenzhuo Lu <wenzhuo.lu@intel.com>;
>> Beilei Xing <beilei.xing@intel.com>; Bernard Iremonger
>> <bernard.iremonger@intel.com>; Ori Kam <orika@nvidia.com>
>> Cc: dev@dpdk.org
>> Subject: Re: [PATCH v2] app/testpmd: support age shared action context
>>
>> On 11/9/2020 10:38 AM, Matan Azrad wrote:
>>>
>>>
>>> From: Ferruh Yigit
>>>> 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 <matan@nvidia.com>
>>>>>>> Acked-by: Dekel Peled <dekelp@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.
>>>
>>> Yes, Now I suggest even better one 😊
>>>
>>>>
>>>> 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.
>>>
>>> Think about big scale.
>>> It is not only memory (malloc overhead + ~16B) but also time
>> consuming(malloc).
>>>
>>> If we have solution that no need malloc and can do things faster, why not to
>> take it?
>>> I don't see here a bug - malloc alignment is a known topic - it should be at
>> least the size of the biggest primitive type.
>>>
>>
>> I can see there is a cost, either with malloc/free, or traverse the list to find
>> 'id', but updating memory pointer that you will use later to carry more
>> metadata
>> looks hack and error prone to me.
>>
>> One can do these kind of tricks on their application, but for testpmd which is
>> for testing and reference I didn't like the idea.
>
> I know I'm jumping a bit late, I have a different suggestion.
> What about creating new struct
> Struct context_type {
> uint8_t type; /**< holds the type of the context can be enum. */
> }
> This struct should be added to both shared context and flow.
> When adding context to the aging action we add the pointer to this struct.
>
> Then when getting the context pointer we cast it to struct context_type,
> get the value, and based on the type we use parentof function to get to the
> pointer of the original structure.
>
> The advantages:
> 1. Just adding one uint8_t to each struct. (not wasting space).
> 2. Very fast lookup since we just add if on the type and then
> use parentof.
> 3. No major changes in structs.
> 4. Not an hack.
> 5. save extra allocation.
> 6. can be expended to support future types.
>
> What do you think?
>
Hi Ori, Matan,
Looks good to me, this is more like first version of the patch but with
'parentof' usage it is safer I think.
From: Ferruh Yigit
> On 11/10/2020 8:30 AM, Ori Kam wrote:
> > Hi,
> > Ferruh and Matan,
> >
> >> -----Original Message-----
> >> From: Ferruh Yigit <ferruh.yigit@intel.com>
> >> Sent: Monday, November 9, 2020 1:13 PM
> >> To: Matan Azrad <matan@nvidia.com>; Wenzhuo Lu
> >> <wenzhuo.lu@intel.com>; Beilei Xing <beilei.xing@intel.com>; Bernard
> >> Iremonger <bernard.iremonger@intel.com>; Ori Kam <orika@nvidia.com>
> >> Cc: dev@dpdk.org
> >> Subject: Re: [PATCH v2] app/testpmd: support age shared action
> >> context
> >>
> >> On 11/9/2020 10:38 AM, Matan Azrad wrote:
> >>>
> >>>
> >>> From: Ferruh Yigit
> >>>> 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 <matan@nvidia.com>
> >>>>>>> Acked-by: Dekel Peled <dekelp@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.
> >>>
> >>> Yes, Now I suggest even better one 😊
> >>>
> >>>>
> >>>> 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.
> >>>
> >>> Think about big scale.
> >>> It is not only memory (malloc overhead + ~16B) but also time
> >> consuming(malloc).
> >>>
> >>> If we have solution that no need malloc and can do things faster,
> >>> why not to
> >> take it?
> >>> I don't see here a bug - malloc alignment is a known topic - it
> >>> should be at
> >> least the size of the biggest primitive type.
> >>>
> >>
> >> I can see there is a cost, either with malloc/free, or traverse the
> >> list to find 'id', but updating memory pointer that you will use
> >> later to carry more metadata looks hack and error prone to me.
> >>
> >> One can do these kind of tricks on their application, but for testpmd
> >> which is for testing and reference I didn't like the idea.
> >
> > I know I'm jumping a bit late, I have a different suggestion.
> > What about creating new struct
> > Struct context_type {
> > uint8_t type; /**< holds the type of the context can be enum. */
> > } This struct should be added to both shared context and flow.
> > When adding context to the aging action we add the pointer to this struct.
> >
> > Then when getting the context pointer we cast it to struct
> > context_type, get the value, and based on the type we use parentof
> > function to get to the pointer of the original structure.
> >
> > The advantages:
> > 1. Just adding one uint8_t to each struct. (not wasting space).
> > 2. Very fast lookup since we just add if on the type and then use
> > parentof.
> > 3. No major changes in structs.
> > 4. Not an hack.
> > 5. save extra allocation.
> > 6. can be expended to support future types.
> >
> > What do you think?
> >
>
> Hi Ori, Matan,
>
> Looks good to me, this is more like first version of the patch but with 'parentof'
> usage it is safer I think.
Ok, will send v3 soon.
Thanks Ferruh and Ori
@@ -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;
+}
+
+static void *
+parse_age_action_context(void *ctx, enum action_age_context_type *type)
+
+{
+ uintptr_t value = (uintptr_t)ctx;
+
+ *type = (enum action_age_context_type)(value & AGE_ACTION_TYPE_MASK);
+ value &= ~(uintptr_t)AGE_ACTION_TYPE_MASK;
+ return (void *)value;
+}
+
static struct port_shared_action *
action_get_by_id(portid_t port_id, uint32_t id)
{
@@ -1849,6 +1876,14 @@ void port_flow_tunnel_create(portid_t port_id, const struct tunnel_ops *ops)
ret = action_alloc(port_id, id, &psa);
if (ret)
return ret;
+ if (action->type == RTE_FLOW_ACTION_TYPE_AGE) {
+ struct rte_flow_action_age *age =
+ (struct rte_flow_action_age *)(uintptr_t)(action->conf);
+
+ set_age_action_context(&age->context,
+ ACTION_AGE_CONTEXT_TYPE_SHARED_ACTION,
+ psa);
+ }
/* Poisoning to make sure PMDs update it in case of error. */
memset(&error, 0x22, sizeof(error));
psa->action = rte_flow_shared_action_create(port_id, conf, action,
@@ -2113,24 +2148,20 @@ struct rte_flow_shared_action *
return 0;
}
-/** Update age action context by port_flow pointer. */
-void
-update_age_action_context(const struct rte_flow_action *actions,
- struct port_flow *pf)
+/** Return age action structure if exists, otherwise NULL. */
+static struct rte_flow_action_age *
+age_action_get(const struct rte_flow_action *actions)
{
- struct rte_flow_action_age *age = NULL;
-
for (; actions->type != RTE_FLOW_ACTION_TYPE_END; actions++) {
switch (actions->type) {
case RTE_FLOW_ACTION_TYPE_AGE:
- age = (struct rte_flow_action_age *)
+ return (struct rte_flow_action_age *)
(uintptr_t)actions->conf;
- age->context = pf;
- return;
default:
break;
}
}
+ return NULL;
}
/** Create flow rule. */
@@ -2147,6 +2178,7 @@ struct rte_flow_shared_action *
uint32_t id = 0;
struct rte_flow_error error;
struct port_flow_tunnel *pft = NULL;
+ struct rte_flow_action_age *age = age_action_get(actions);
port = &ports[port_id];
if (port->flow_list) {
@@ -2170,7 +2202,9 @@ struct rte_flow_shared_action *
pf = port_flow_new(attr, pattern, actions, &error);
if (!pf)
return port_flow_complain(&error);
- update_age_action_context(actions, pf);
+ if (age)
+ set_age_action_context(&age->context,
+ ACTION_AGE_CONTEXT_TYPE_FLOW, pf);
/* Poisoning to make sure PMDs update it in case of error. */
memset(&error, 0x22, sizeof(error));
flow = rte_flow_create(port_id, attr, pattern, actions, &error);
@@ -2379,7 +2413,12 @@ struct rte_flow_shared_action *
void **contexts;
int nb_context, total = 0, idx;
struct rte_flow_error error;
- struct port_flow *pf;
+ enum action_age_context_type type;
+ union {
+ struct port_flow *pf;
+ struct port_shared_action *psa;
+ void *obj;
+ } ctx;
if (port_id_is_invalid(port_id, ENABLED_WARN) ||
port_id == (portid_t)RTE_PORT_ALL)
@@ -2397,7 +2436,7 @@ struct rte_flow_shared_action *
printf("Cannot allocate contexts for aged flow\n");
return;
}
- printf("ID\tGroup\tPrio\tAttr\n");
+ printf("%-20s\tID\tGroup\tPrio\tAttr\n", "Type");
nb_context = rte_flow_get_aged_flows(port_id, contexts, total, &error);
if (nb_context != total) {
printf("Port:%d get aged flows count(%d) != total(%d)\n",
@@ -2405,37 +2444,43 @@ struct rte_flow_shared_action *
free(contexts);
return;
}
+ total = 0;
for (idx = 0; idx < nb_context; idx++) {
- pf = (struct port_flow *)contexts[idx];
- if (!pf) {
+ if (!contexts[idx]) {
printf("Error: get Null context in port %u\n", port_id);
continue;
}
- printf("%" PRIu32 "\t%" PRIu32 "\t%" PRIu32 "\t%c%c%c\t\n",
- pf->id,
- pf->rule.attr->group,
- pf->rule.attr->priority,
- pf->rule.attr->ingress ? 'i' : '-',
- pf->rule.attr->egress ? 'e' : '-',
- pf->rule.attr->transfer ? 't' : '-');
- }
- if (destroy) {
- int ret;
- uint32_t flow_id;
-
- total = 0;
- printf("\n");
- for (idx = 0; idx < nb_context; idx++) {
- pf = (struct port_flow *)contexts[idx];
- if (!pf)
- continue;
- flow_id = pf->id;
- ret = port_flow_destroy(port_id, 1, &flow_id);
- if (!ret)
- total++;
+ ctx.obj = parse_age_action_context(contexts[idx], &type);
+ if (!ctx.obj) {
+ printf("Error: get Null age context in port %u\n",
+ port_id);
+ continue;
+ }
+ switch (type) {
+ case ACTION_AGE_CONTEXT_TYPE_FLOW:
+ printf("%-20s\t%" PRIu32 "\t%" PRIu32 "\t%" PRIu32
+ "\t%c%c%c\t\n",
+ "Flow",
+ ctx.pf->id,
+ ctx.pf->rule.attr->group,
+ ctx.pf->rule.attr->priority,
+ ctx.pf->rule.attr->ingress ? 'i' : '-',
+ ctx.pf->rule.attr->egress ? 'e' : '-',
+ ctx.pf->rule.attr->transfer ? 't' : '-');
+ if (destroy && !port_flow_destroy(port_id, 1,
+ &ctx.pf->id))
+ total++;
+ break;
+ case ACTION_AGE_CONTEXT_TYPE_SHARED_ACTION:
+ printf("%-20s\t%" PRIu32 "\n", "Shared action",
+ ctx.psa->id);
+ break;
+ default:
+ printf("Error: invalid context type %u\n", port_id);
+ break;
}
- printf("%d flows be destroyed\n", total);
}
+ printf("\n%d flows destroyed\n", total);
free(contexts);
}
@@ -143,6 +143,11 @@ struct fwd_stream {
struct pkt_burst_stats tx_burst_stats;
};
+enum action_age_context_type {
+ ACTION_AGE_CONTEXT_TYPE_FLOW,
+ ACTION_AGE_CONTEXT_TYPE_SHARED_ACTION,
+};
+
/** Descriptor for a single flow. */
struct port_flow {
struct port_flow *next; /**< Next flow in list. */