DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Ori Kam <orika@nvidia.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 09:43:56 +0000
Message-ID: <8859b571-ffb8-4dc5-d0c4-3dc455ac6a40@intel.com> (raw)
In-Reply-To: <DM6PR12MB4987C643F7807AD8DE635F21D6E90@DM6PR12MB4987.namprd12.prod.outlook.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.


  reply	other threads:[~2020-11-10  9:44 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 [this message]
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=8859b571-ffb8-4dc5-d0c4-3dc455ac6a40@intel.com \
    --to=ferruh.yigit@intel.com \
    --cc=beilei.xing@intel.com \
    --cc=bernard.iremonger@intel.com \
    --cc=dev@dpdk.org \
    --cc=matan@nvidia.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