From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, HK_RANDOM_FROM,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46224C5DF60 for ; Fri, 8 Nov 2019 15:04:48 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id DCE25215EA for ; Fri, 8 Nov 2019 15:04:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DCE25215EA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E4ED21C22F; Fri, 8 Nov 2019 16:04:46 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 46FBD1C22D for ; Fri, 8 Nov 2019 16:04:45 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2019 07:04:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,281,1569308400"; d="scan'208";a="206011184" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga003.jf.intel.com with ESMTP; 08 Nov 2019 07:04:43 -0800 Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 8 Nov 2019 07:04:43 -0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx116.amr.corp.intel.com (10.18.116.20) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 8 Nov 2019 07:04:43 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.108]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.127]) with mapi id 14.03.0439.000; Fri, 8 Nov 2019 23:04:41 +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: AQHVlVkh3iu4v6QT1Ea1hIuvZbOCqqeAsOSAgACepsD//4RxAIAAjJAg Date: Fri, 8 Nov 2019 15:04:41 +0000 Message-ID: References: <20191105011918.53434-1-haiyue.wang@intel.com> <1962515.WBHSJCFqR1@xps> <2644972.cy8Zfzkded@xps> In-Reply-To: <2644972.cy8Zfzkded@xps> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNWM1YjQ4ZjktNmI5OC00MDViLWI0ZjMtMmU4YTY4NDhjMGU3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiclRzcTJHMlVjK0d1RVhZamlwRDRhVjlrRE00Ukw1UWttYlVDelJ3elJnQ1Y2cmFrRW1cLysyb0NTdE5MdEFzbUoifQ== 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" > -----Original Message----- > From: Thomas Monjalon > Sent: Friday, November 8, 2019 22:40 > 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 > 08/11/2019 15:08, Wang, Haiyue: > > 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 extract= ion by dynamic mbuf API > > > > > > Hi, > > > > > > I see this patch is already merged in next-net-intel, > > > but please I would prefer to have below improvements first. > > > > > > 07/11/2019 11:44, Haiyue Wang: > > > > The original design is to use rte_mbuf::udata64 to save the metadat= a 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 u= ses > > > > it. It only needs 4B size to save the protocol extraction data, and= its > > > > > > Yes using a dynamic field is definitely more correct. > > > > > > > type and validity is indicated by related bit in 'rte_mbuf::ol_flag= s'. > > > > > > Better to say explicitly it uses a dynamic flag. > > > > > > > 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 pr= ior notice > > > > + * > > > > + */ > > > > > > Adding the file in doxygen is good. > > > I think it could be a separate patch for doxygen + cleanups. > > > > > > > +/** > > > > + * The supported network protocol extraction metadata format. > > > > + */ > > > > +union proto_xtr_metadata { > > > > -struct proto_xtr_flds { > > > > > > Please add a prefix rte_ice_ or rte_net_ice_ as you wish. > > > > > > > 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 me= tadata, 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 valid > > > > + * when dev_args 'proto_xtr' has 'tcp' specified. > > > > + */ > > > > +#define PKT_RX_DYNF_PROTO_XTR_TCP \ > > > > + (rte_net_ice_dynflag_proto_xtr_tcp_mask) > > > > > > Those fields and flags are missing a RTE_ prefix. > > > (Yes I know we are missing such prefix in rte_mbuf.f) > > > > > > > The "PKT_RX_" in ' lib/librte_mbuf/rte_mbuf_core.h' will be changed to > > "RTE_PKT_RX_" ? >=20 > I started to do such change a long time ago and never finished. > Yes it will be changed for 20.11. >=20 > > Or keep the above as it is now, to keep the same ol_flags style, until = all > > the "PKT_RX_" are changed ? >=20 > Please I prefer you change yours, without waiting global change. >=20 OK, will update it.