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 2217FA034E; Thu, 7 Nov 2019 11:38:35 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E8A4D1E8F8; Thu, 7 Nov 2019 11:38:33 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 030691E8F2 for ; Thu, 7 Nov 2019 11:38:31 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2019 02:38:30 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,277,1569308400"; d="scan'208";a="233215870" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga002.fm.intel.com with ESMTP; 07 Nov 2019 02:38:30 -0800 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 7 Nov 2019 02:38:30 -0800 Received: from shsmsx108.ccr.corp.intel.com (10.239.4.97) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 7 Nov 2019 02:38:29 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.108]) by SHSMSX108.ccr.corp.intel.com ([169.254.8.41]) with mapi id 14.03.0439.000; Thu, 7 Nov 2019 18:38:28 +0800 From: "Wang, Haiyue" To: "Ye, Xiaolong" CC: "dev@dpdk.org" , "olivier.matz@6wind.com" Thread-Topic: [PATCH v8] net/ice: optimize protocol extraction by dynamic mbuf API Thread-Index: AQHVlS4FbECp5ArIcEC63vdW5GLF76d+5WkAgACdD0A= Date: Thu, 7 Nov 2019 10:38:27 +0000 Message-ID: References: <20191105011918.53434-1-haiyue.wang@intel.com> <20191107053532.52375-1-haiyue.wang@intel.com> <20191107090838.GE100445@intel.com> In-Reply-To: <20191107090838.GE100445@intel.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDE2ZDU3MTUtMzc2Zi00YTliLTlkYTQtYjZkY2M2OGMyODc1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiNU1WekpldHZMbmFoVVh5bStZMW1Qb2NFS29hcHFnTytMcjdLZ3FnQklqd2xGeWliVjQxSW02TlVGVXhBM0sweiJ9 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 v8] 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 Xiaolong, > -----Original Message----- > From: Ye, Xiaolong > Sent: Thursday, November 7, 2019 17:09 > To: Wang, Haiyue > Cc: dev@dpdk.org; olivier.matz@6wind.com > Subject: Re: [PATCH v8] net/ice: optimize protocol extraction by dynamic = mbuf API >=20 > Hi, Haiyue >=20 > On 11/07, Haiyue Wang wrote: > >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 > >type and validity is indicated by related bit in 'rte_mbuf::ol_flags'. > > > >Signed-off-by: Haiyue Wang > >--- > >v8: - Cleanup the doxgen, rename the dynamic filed and flags with ice pr= efix. > > > >v7: - Change the log level from ERR to DEBUG for a successful registrati= on, > > ERR is used to develop firstly. > > > >v6: - Don't need to register all flags when if one dev_args is set, regi= ster > > it as required. > > > >v5: - Remove the '_OL/_ol' in dynamic mbuf flag to make the variable cle= an. > > > >v4: - Include the 'rte_pmd_ice.h' header in ICE source as needed, reduce > > its compile scope. > > > >v3: - Use the conventions name "rte_net__dynfield_" since it > > is defined in a in PMD. > > - Add helpers API for easiy access. > > > >v2: - disable the protocol extraction if failed to register some ol_flag= s > > - rewrite the commit message > > > > doc/api/doxy-api-index.md | 1 + > > doc/api/doxy-api.conf.in | 1 + > > doc/guides/nics/ice.rst | 14 +- > > drivers/net/ice/ice_ethdev.c | 84 ++++++- > > drivers/net/ice/ice_ethdev.h | 9 + > > drivers/net/ice/ice_rxtx.c | 88 ++++--- > > drivers/net/ice/ice_rxtx.h | 1 - > > drivers/net/ice/rte_pmd_ice.h | 312 +++++++++++++++--------- > > drivers/net/ice/rte_pmd_ice_version.map | 12 + > > 9 files changed, 369 insertions(+), 153 deletions(-) > > >=20 > [snip] >=20 > > > >- The extraction will be copied into the lower 32 bit of ``rte_mbuf::ud= ata64``. > >+ The extraction metadata will be copied into the registered dynamic mb= uf field > >+ with, and the related dynamic mbuf flags is set. >=20 > Above 'with' is redundant? Yes, will fix next version. >=20 > > > > .. table:: Protocol extraction : ``vlan`` > > > >@@ -175,10 +176,11 @@ Runtime Config Options > > > > TCPHDR2 - Reserved > > > >- Use ``get_proto_xtr_flds(struct rte_mbuf *mb)`` to access the protoco= l > >- extraction, do not use ``rte_mbuf::udata64`` directly. > >+ Use ``rte_net_ice_dynf_proto_xtr_metadata_get`` to access the protoco= l > >+ extraction metadata, and use ``PKT_RX_DYNF_PROTO_XTR_*`` to get the > >+ metadata type of ``struct rte_mbuf::ol_flags``. > > > >- The ``dump_proto_xtr_flds(struct rte_mbuf *mb)`` routine shows how to > >+ The ``rte_net_ice_dump_proto_xtr_metadata`` routine shows how to > > access the protocol extraction result in ``struct rte_mbuf``. > > >=20 > [snip] >=20 > >+ > >+ PMD_DRV_LOG(DEBUG, > >+ "Protocol extraction metadata offset in mbuf is : %d", > >+ offset); > >+ rte_net_ice_dynfield_proto_xtr_metadata =3D offset; >=20 > Seems rte_net_ice_dump_proto_xtr_metadata_off is a better name judging fr= om > its real meaning. >=20 Make sense, will change it. > >+ > >+ for (i =3D 0; i < RTE_DIM(ice_proto_xtr_ol_flag_params); i++) { > >+ ol_flag =3D &ice_proto_xtr_ol_flag_params[i]; > >+ > >+ if (!ol_flag->required) >=20 > [snip] >=20 > >+static void > >+ice_rxd_to_proto_xtr(struct rte_mbuf *mb, > >+ volatile struct ice_32b_rx_flex_desc_comms *desc) > >+{ > >+ uint16_t stat_err =3D rte_le_to_cpu_16(desc->status_error1); > >+ uint32_t metadata; > >+ uint64_t ol_flag; > >+ > >+ if (unlikely(!(stat_err & ICE_RX_PROTO_XTR_VALID))) > >+ return; > >+ > >+ ol_flag =3D ice_rxdid_to_proto_xtr_ol_flag(desc->rxdid); >=20 > ol_flag here is obtained through offset which is returned by > rte_mbuf_dynflag_register, will it have any chance to conflict with > existing offload flags such as PKT_RX_VLAN, PKT_RX_VLAN_STRIPPED, ...? >=20 This API will choose between "PKT_FIRST_FREE" and "PKT_LAST_FREE", not conflict. ;-) > >+ if (unlikely(!ol_flag)) > >+ return; > >+ > >+ mb->ol_flags |=3D ol_flag; > >+ >=20 > [snip] >=20 > >--- a/drivers/net/ice/rte_pmd_ice_version.map > >+++ b/drivers/net/ice/rte_pmd_ice_version.map > >@@ -2,3 +2,15 @@ DPDK_19.02 { > > > > local: *; > > }; > >+ > >+EXPERIMENTAL { > >+ global: > >+ > >+ # added in 19.11 > >+ rte_net_ice_dynfield_proto_xtr_metadata; > >+ rte_net_ice_dynflag_proto_xtr_vlan; > >+ rte_net_ice_dynflag_proto_xtr_ipv4; > >+ rte_net_ice_dynflag_proto_xtr_ipv6; > >+ rte_net_ice_dynflag_proto_xtr_ipv6_flow; > >+ rte_net_ice_dynflag_proto_xtr_tcp; >=20 > Why put the variable other than the experimental api in the map? >=20 The experimental API is static and inline, not global, so no need to be put here. But the above variables are global, so need to be put here for compiling shared. Please refer to: git log -p lib/librte_ethdev/rte_ethdev_version.map > Thanks, > Xiaolong >=20 > >+}; > >-- > >2.17.1 > >