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 520A5A04B4; Fri, 8 Nov 2019 15:08:22 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EC4641C1CA; Fri, 8 Nov 2019 15:08:21 +0100 (CET) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id A97901C1C4 for ; Fri, 8 Nov 2019 15:08:19 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2019 06:08:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,281,1569308400"; d="scan'208";a="232808669" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by FMSMGA003.fm.intel.com with ESMTP; 08 Nov 2019 06:08:18 -0800 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 8 Nov 2019 06:08:18 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 8 Nov 2019 06:08:18 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.108]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.60]) with mapi id 14.03.0439.000; Fri, 8 Nov 2019 22:08:16 +0800 From: "Wang, Haiyue" To: Thomas Monjalon CC: "dev@dpdk.org" , "olivier.matz@6wind.com" , "Ye, Xiaolong" , "Yigit, Ferruh" Thread-Topic: [dpdk-dev] [PATCH v9] net/ice: optimize protocol extraction by dynamic mbuf API Thread-Index: AQHVlVkh3iu4v6QT1Ea1hIuvZbOCqqeAsOSAgACepsA= Date: Fri, 8 Nov 2019 14:08:16 +0000 Message-ID: References: <20191105011918.53434-1-haiyue.wang@intel.com> <20191107104402.99398-1-haiyue.wang@intel.com> <1962515.WBHSJCFqR1@xps> In-Reply-To: <1962515.WBHSJCFqR1@xps> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZWM3MmRmNmMtNWMwMS00ZGE5LWI2NGUtNjJlN2E2OWE5OThkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiZFZMYmI1NlN0MW45cmhIRDFYT1B6c0grYmluMUxkUklmQVpDR0pNVVNhOStqWW9aYmlDRjhkNnFOMGllMjBcL0cifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v9] net/ice: optimize protocol extraction by dynamic mbuf API 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" Hi Thomas, > -----Original Message----- > From: Thomas Monjalon > Sent: Friday, November 8, 2019 20:34 > To: Wang, Haiyue > Cc: dev@dpdk.org; olivier.matz@6wind.com; Ye, Xiaolong ; Yigit, Ferruh > > Subject: Re: [dpdk-dev] [PATCH v9] net/ice: optimize protocol extraction = by dynamic mbuf API >=20 > Hi, >=20 > I see this patch is already merged in next-net-intel, > but please I would prefer to have below improvements first. >=20 > 07/11/2019 11:44, Haiyue Wang: > > The original design is to use rte_mbuf::udata64 to save the metadata of > > protocol extraction which has network protocol data fields and type, a > > private API is used to decode this metadata. > > > > Use the dynamic mbuf field and flags to register the needed fields in > > mbuf, to avoid overwriting 'rte_mbuf::udata64' if the application uses > > it. It only needs 4B size to save the protocol extraction data, and its >=20 > Yes using a dynamic field is definitely more correct. >=20 > > type and validity is indicated by related bit in 'rte_mbuf::ol_flags'. >=20 > Better to say explicitly it uses a dynamic flag. >=20 Will update doc to make the description be better. > > --- a/drivers/net/ice/rte_pmd_ice.h > > +++ b/drivers/net/ice/rte_pmd_ice.h > > +/** > > + * @file rte_pmd_ice.h > > + * > > + * ice PMD specific functions. > > + * > > + * @b EXPERIMENTAL: this API may change, or be removed, without prior = notice > > + * > > + */ >=20 > Adding the file in doxygen is good. > I think it could be a separate patch for doxygen + cleanups. >=20 > > +/** > > + * The supported network protocol extraction metadata format. > > + */ > > +union proto_xtr_metadata { > > -struct proto_xtr_flds { >=20 > Please add a prefix rte_ice_ or rte_net_ice_ as you wish. >=20 Missed, will be updated. > [...] > > +/** > > + * The mbuf dynamic flag for VLAN protocol extraction metadata, it is = valid > > + * when dev_args 'proto_xtr' has 'vlan' specified. > > + */ > > +#define PKT_RX_DYNF_PROTO_XTR_VLAN \ > > + (rte_net_ice_dynflag_proto_xtr_vlan_mask) > > + > > +/** > > + * The mbuf dynamic flag for IPv4 protocol extraction metadata, it is = valid > > + * when dev_args 'proto_xtr' has 'ipv4' specified. > > + */ > > +#define PKT_RX_DYNF_PROTO_XTR_IPV4 \ > > + (rte_net_ice_dynflag_proto_xtr_ipv4_mask) > > + > > +/** > > + * The mbuf dynamic flag for IPv6 protocol extraction metadata, it is = valid > > + * when dev_args 'proto_xtr' has 'ipv6' specified. > > + */ > > +#define PKT_RX_DYNF_PROTO_XTR_IPV6 \ > > + (rte_net_ice_dynflag_proto_xtr_ipv6_mask) > > + > > +/** > > + * The mbuf dynamic flag for IPv6 with flow protocol extraction metada= ta, it is > > + * valid when dev_args 'proto_xtr' has 'ipv6_flow' specified. > > + */ > > +#define PKT_RX_DYNF_PROTO_XTR_IPV6_FLOW \ > > + (rte_net_ice_dynflag_proto_xtr_ipv6_flow_mask) > > + > > +/** > > + * The mbuf dynamic flag for TCP protocol extraction metadata, it is v= alid > > + * when dev_args 'proto_xtr' has 'tcp' specified. > > + */ > > +#define PKT_RX_DYNF_PROTO_XTR_TCP \ > > + (rte_net_ice_dynflag_proto_xtr_tcp_mask) >=20 > Those fields and flags are missing a RTE_ prefix. > (Yes I know we are missing such prefix in rte_mbuf.f) >=20 The "PKT_RX_" in ' lib/librte_mbuf/rte_mbuf_core.h' will be changed to "RTE_PKT_RX_" ? Or keep the above as it is now, to keep the same ol_flags style, until all the "PKT_RX_" are changed ?