Re: [dpdk-dev] [PATCH v2] app/testpmd: support age shared action context

[Ferruh Yigit <ferruh.yigit@intel.com>]

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.