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

[Matan Azrad]

From: Ferruh Yigit
> On 11/10/2020 8:30 AM, Ori Kam wrote:
> > Hi,
> > Ferruh and Matan,
> >
> >> -----Original Message-----
> >> From: Ferruh Yigit <ferruh.yigit at intel.com>
> >> Sent: Monday, November 9, 2020 1:13 PM
> >> To: Matan Azrad <matan at nvidia.com>; Wenzhuo Lu
> >> <wenzhuo.lu at intel.com>; Beilei Xing <beilei.xing at intel.com>; Bernard
> >> Iremonger <bernard.iremonger at intel.com>; Ori Kam <orika at nvidia.com>
> >> Cc: dev at 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 at nvidia.com>
> >>>>>>> Acked-by: Dekel Peled <dekelp at 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