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 5A6EAA034E; Thu, 7 Nov 2019 10:12:46 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2B63D1E980; Thu, 7 Nov 2019 10:12:46 +0100 (CET) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 6A73A1E97A for ; Thu, 7 Nov 2019 10:12:44 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2019 01:12:43 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,277,1569308400"; d="scan'208";a="285940884" Received: from yexl-server.sh.intel.com (HELO localhost) ([10.67.117.17]) by orsmga001.jf.intel.com with ESMTP; 07 Nov 2019 01:12:42 -0800 Date: Thu, 7 Nov 2019 17:08:38 +0800 From: Ye Xiaolong To: Haiyue Wang Cc: dev@dpdk.org, olivier.matz@6wind.com Message-ID: <20191107090838.GE100445@intel.com> References: <20191105011918.53434-1-haiyue.wang@intel.com> <20191107053532.52375-1-haiyue.wang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191107053532.52375-1-haiyue.wang@intel.com> User-Agent: Mutt/1.9.4 (2018-02-28) 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, Haiyue 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 prefix. > >v7: - Change the log level from ERR to DEBUG for a successful registration, > ERR is used to develop firstly. > >v6: - Don't need to register all flags when if one dev_args is set, register > it as required. > >v5: - Remove the '_OL/_ol' in dynamic mbuf flag to make the variable clean. > >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_flags > - 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(-) > [snip] > >- The extraction will be copied into the lower 32 bit of ``rte_mbuf::udata64``. >+ The extraction metadata will be copied into the registered dynamic mbuf field >+ with, and the related dynamic mbuf flags is set. Above 'with' is redundant? > > .. 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 protocol >- extraction, do not use ``rte_mbuf::udata64`` directly. >+ Use ``rte_net_ice_dynf_proto_xtr_metadata_get`` to access the protocol >+ 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``. > [snip] >+ >+ PMD_DRV_LOG(DEBUG, >+ "Protocol extraction metadata offset in mbuf is : %d", >+ offset); >+ rte_net_ice_dynfield_proto_xtr_metadata = offset; Seems rte_net_ice_dump_proto_xtr_metadata_off is a better name judging from its real meaning. >+ >+ for (i = 0; i < RTE_DIM(ice_proto_xtr_ol_flag_params); i++) { >+ ol_flag = &ice_proto_xtr_ol_flag_params[i]; >+ >+ if (!ol_flag->required) [snip] >+static void >+ice_rxd_to_proto_xtr(struct rte_mbuf *mb, >+ volatile struct ice_32b_rx_flex_desc_comms *desc) >+{ >+ uint16_t stat_err = 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 = ice_rxdid_to_proto_xtr_ol_flag(desc->rxdid); 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, ...? >+ if (unlikely(!ol_flag)) >+ return; >+ >+ mb->ol_flags |= ol_flag; >+ [snip] >--- 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; Why put the variable other than the experimental api in the map? Thanks, Xiaolong >+}; >-- >2.17.1 >