From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3E352A04B5; Fri, 6 Nov 2020 14:58:03 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 65AF772E2; Fri, 6 Nov 2020 14:58:01 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 8D50E697A for ; Fri, 6 Nov 2020 14:57:59 +0100 (CET) IronPort-SDR: hT+/epUmVjksAhYV0QzHHPKfCDsJ/3xgk+2/g10FngsncLAR+lk3qyupMbNEQX/jIGihqwkJpX rsD/+CyML8zQ== X-IronPort-AV: E=McAfee;i="6000,8403,9796"; a="169694462" X-IronPort-AV: E=Sophos;i="5.77,456,1596524400"; d="scan'208";a="169694462" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2020 05:57:56 -0800 IronPort-SDR: qDtGDaoEeNg6dLzjQUAqzrleGyW453snf+KAojpsiDf4AbeVPbsvHmHEISrioUgRS+Ob0MAaRC UBdOSvq+kHuA== X-IronPort-AV: E=Sophos;i="5.77,456,1596524400"; d="scan'208";a="539847009" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.228.45]) ([10.213.228.45]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2020 05:57:55 -0800 To: Matan Azrad , Wenzhuo Lu , Beilei Xing , Bernard Iremonger , Ori Kam Cc: dev@dpdk.org References: <1604252927-213452-1-git-send-email-matan@nvidia.com> <1604611973-64970-1-git-send-email-matan@nvidia.com> From: Ferruh Yigit Message-ID: <970eeb8a-b18b-fc89-7659-02fa6020d19b@intel.com> Date: Fri, 6 Nov 2020 13:57:51 +0000 MIME-Version: 1.0 In-Reply-To: <1604611973-64970-1-git-send-email-matan@nvidia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v2] app/testpmd: support age shared action context X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > Acked-by: Dekel Peled > --- > 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. 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?