From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5F8F4A00BE; Wed, 20 Apr 2022 15:42:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 006E040C35; Wed, 20 Apr 2022 15:42:56 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 470DF406A2 for ; Wed, 20 Apr 2022 15:42:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650462175; x=1681998175; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kUwUGJQHoQ8DilepdV9kYAGe7uDqRF6s21n/BG/faI8=; b=kaGk/KakpQRogyqmys3yJ/bPGdvDoAoM/VbbDp2Q9s/jiQmjsNLncIdK EuhXNfbegLjQ4ImWMSz1MzMrtZWc67kBiSn6caBD4K8p/JkvuUkfd9hRh a0qa+i9uqlEibCPD7VXeQ5zhpOhhewT8/q7cePDQA4HXQsoo8AOLZjIsj virbg3mSuM9FNsyZqXTtlm6F2sm4vWXgCQjYeSrbxHXccrrQW8l2imuF/ +x/FuvFwgkWmBoltsouCjA2XsBC8mJzzYRj2CXyNQEaBkFGL57cZb3DU7 KTaceUtM6IMg0Hk8+/+iOuiOjDixcOjQOg2840m4aGUXD4Sk+TFfuPtfT g==; X-IronPort-AV: E=McAfee;i="6400,9594,10322"; a="326926131" X-IronPort-AV: E=Sophos;i="5.90,275,1643702400"; d="scan'208";a="326926131" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2022 06:42:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,275,1643702400"; d="scan'208";a="555198835" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by orsmga007.jf.intel.com with ESMTP; 20 Apr 2022 06:42:53 -0700 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Wed, 20 Apr 2022 06:42:53 -0700 Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by fmsmsx605.amr.corp.intel.com ([10.18.126.85]) with mapi id 15.01.2308.027; Wed, 20 Apr 2022 06:42:53 -0700 From: "Zhang, Qi Z" To: Ray Kinsella , "Zhang, Peng1X" CC: "dev@dpdk.org" , "Yang, Qiming" , "Richardson, Bruce" Subject: RE: [PATCH] net/ice: promote dynflag API Thread-Topic: [PATCH] net/ice: promote dynflag API Thread-Index: AQHYT8k/Qx/8g0qQB0KcamrT62iHF6z34aoAgADwR1A= Date: Wed, 20 Apr 2022 13:42:53 +0000 Message-ID: <2eebde896fa74cb89d22095f0729125f@intel.com> References: <20220414062510.207983-1-peng1x.zhang@intel.com> <87k0blnk3b.fsf@mdr78.vserver.site> In-Reply-To: <87k0blnk3b.fsf@mdr78.vserver.site> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.6.401.20 dlp-product: dlpe-windows x-originating-ip: [10.239.127.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > -----Original Message----- > From: Ray Kinsella > Sent: Tuesday, April 19, 2022 11:56 PM > To: Zhang, Peng1X > Cc: dev@dpdk.org; Yang, Qiming ; Zhang, Qi Z > ; Richardson, Bruce > Subject: Re: [PATCH] net/ice: promote dynflag API >=20 >=20 > peng1x.zhang@intel.com writes: >=20 > > From: Peng Zhang > > > > Promote dynflag APIs to be stable. > > > > Signed-off-by: Peng Zhang > > --- > > drivers/net/ice/rte_pmd_ice.h | 1 - > > drivers/net/ice/version.map | 15 +++++++++------ > > 2 files changed, 9 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/net/ice/rte_pmd_ice.h > > b/drivers/net/ice/rte_pmd_ice.h index 9a436a140b..13604bf9e2 100644 > > --- a/drivers/net/ice/rte_pmd_ice.h > > +++ b/drivers/net/ice/rte_pmd_ice.h > > @@ -149,7 +149,6 @@ extern uint64_t > rte_net_ice_dynflag_proto_xtr_ip_offset_mask; > > * @return > > * True if registered, false otherwise. > > */ > > -__rte_experimental > > static __rte_always_inline int > > rte_net_ice_dynf_proto_xtr_metadata_avail(void) > > { > > diff --git a/drivers/net/ice/version.map b/drivers/net/ice/version.map > > index cc837f1c00..4cbe33a40d 100644 > > --- a/drivers/net/ice/version.map > > +++ b/drivers/net/ice/version.map > > @@ -1,16 +1,19 @@ > > DPDK_22 { > > - local: *; > > -}; > > + global: > > > > -EXPERIMENTAL { > > - global: > > - > > - # added in 19.11 > > rte_net_ice_dynfield_proto_xtr_metadata_offs; > > rte_net_ice_dynflag_proto_xtr_vlan_mask; > > rte_net_ice_dynflag_proto_xtr_ipv4_mask; > > rte_net_ice_dynflag_proto_xtr_ipv6_mask; > > rte_net_ice_dynflag_proto_xtr_ipv6_flow_mask; > > rte_net_ice_dynflag_proto_xtr_tcp_mask; >=20 > Folks, these are all exported variables, we should be removing these not > promoting these to stable. After looking at them closely, can't we just m= ake > them local, do they need to be exported at all? These are help API we exposed to the application, they should be used paire= d with devargs "proto_xtr". Basically, the application use proto_xtr to offload specific metadata to a = customized mbuf,=20 The driver uses dynamic mbuf API to register the field and store the mbuf o= ffset to the above global variables, then the application uses them to acce= ss specific metadata. So I think they are not local. >=20 > -- > Regards, Ray K