DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ori Kam <orika@nvidia.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
	Matan Azrad <matan@nvidia.com>, Wenzhuo Lu <wenzhuo.lu@intel.com>,
	Beilei Xing <beilei.xing@intel.com>,
	Bernard Iremonger <bernard.iremonger@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2] app/testpmd: support age shared action context
Date: Tue, 10 Nov 2020 08:30:13 +0000	[thread overview]
Message-ID: <DM6PR12MB4987C643F7807AD8DE635F21D6E90@DM6PR12MB4987.namprd12.prod.outlook.com> (raw)
In-Reply-To: <410fbc60-93f7-c810-3d2e-0fd2216f34a5@intel.com>

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


  reply	other threads:[~2020-11-10  8:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-01 17:48 [dpdk-dev] [PATCH] " Matan Azrad
2020-11-02 18:50 ` Ferruh Yigit
2020-11-03  7:33   ` Matan Azrad
2020-11-04 12:58     ` Ferruh Yigit
2020-11-04 13:28       ` Matan Azrad
2020-11-04 13:45         ` Ferruh Yigit
2020-11-05 21:32 ` [dpdk-dev] [PATCH v2] " Matan Azrad
2020-11-06 13:57   ` Ferruh Yigit
2020-11-07 17:30     ` Matan Azrad
2020-11-09 10:21       ` Ferruh Yigit
2020-11-09 10:38         ` Matan Azrad
2020-11-09 11:12           ` Ferruh Yigit
2020-11-10  8:30             ` Ori Kam [this message]
2020-11-10  9:43               ` Ferruh Yigit
2020-11-10 10:58                 ` Matan Azrad
2020-11-10 17:06   ` [dpdk-dev] [PATCH v3] " Matan Azrad
2020-11-11 12:51     ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM6PR12MB4987C643F7807AD8DE635F21D6E90@DM6PR12MB4987.namprd12.prod.outlook.com \
    --to=orika@nvidia.com \
    --cc=beilei.xing@intel.com \
    --cc=bernard.iremonger@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=matan@nvidia.com \
    --cc=wenzhuo.lu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).