DPDK patches and discussions
 help / color / mirror / Atom feed
From: Matan Azrad <matan@nvidia.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>, Ori Kam <orika@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 10:58:38 +0000
Message-ID: <MW2PR12MB2492EFA031AA3B5956007DFDDFE90@MW2PR12MB2492.namprd12.prod.outlook.com> (raw)
In-Reply-To: <8859b571-ffb8-4dc5-d0c4-3dc455ac6a40@intel.com>



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


  reply	other threads:[~2020-11-10 10:58 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
2020-11-10  9:43               ` Ferruh Yigit
2020-11-10 10:58                 ` Matan Azrad [this message]
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=MW2PR12MB2492EFA031AA3B5956007DFDDFE90@MW2PR12MB2492.namprd12.prod.outlook.com \
    --to=matan@nvidia.com \
    --cc=beilei.xing@intel.com \
    --cc=bernard.iremonger@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=orika@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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git