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 EC2E1A04B4; Fri, 8 Nov 2019 15:38:15 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BD69A1C1E0; Fri, 8 Nov 2019 15:38:14 +0100 (CET) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id ACF281C0B5 for ; Fri, 8 Nov 2019 15:38:13 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 7F5D8521; Fri, 8 Nov 2019 09:38:12 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 08 Nov 2019 09:38:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=uVxIp4sD6YliYNLcFb/JIgkKoFXTHMWymCgs6MZoxuw=; b=VIIfPCrcyXZH c3uf7D7pt8f0i7MafuZPpvK5/GW1cVlKDDj/Q5/3m635UcpYUWG9KkXjRlHNjpnk tghBVBAFFR0inQ7dPKi2+4YpY8EaMH9gerfkjlYaOjQe5J0gVfo+ESey1YvFnpUp XXmg9HTzYgXZXsWH70oMUY5XB0a5wr8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=uVxIp4sD6YliYNLcFb/JIgkKoFXTHMWymCgs6MZox uw=; b=BeQ9PkZUjVXuur1igleIFjLGe8rMOisdMWmOnlSofl5cFSV/QZqYlGnSr AcsNyv8PnI8ZenXKNHUt71rYy+MbNko+whhm6yz/4wiG2UVgOzAcFj/ZhN76NvJe QhJ9+CZ/sh09ZM9aWHUbfr2Z2px7spg7oeT3IZnUVJMBsKl7HKuVg6cf47jcwq0k twOzB51Zo/D314c/hS9nYqjy4G4AvjwoggMKDSmdOxwVFbBDv5JKzVP1fwnPDDbu c7Idwkfx+rFgL1u2pgWpa6rTmYQku6LeqFjf76SDbY05kVNKbfXnHRWcGwmheX0y FWfueI+hSzIr96PXrjcg9CIq6eL4A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddvuddgieekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpehthhgvrdhmrghpnecukfhppeejjedrudefgedrvddtfedrudekgeenucfr rghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvthenuc evlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 73D758005C; Fri, 8 Nov 2019 09:38:10 -0500 (EST) From: Thomas Monjalon To: "Wang, Haiyue" Cc: "dev@dpdk.org" , "olivier.matz@6wind.com" , "Ye, Xiaolong" , "Yigit, Ferruh" Date: Fri, 08 Nov 2019 15:38:09 +0100 Message-ID: <2380965.TJoCyOKrBI@xps> In-Reply-To: References: <20191105011918.53434-1-haiyue.wang@intel.com> <3014726.q9f2PGURN9@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 08/11/2019 15:01, Wang, Haiyue: > From: Thomas Monjalon > > 07/11/2019 11:44, Haiyue Wang: > > > --- a/drivers/net/ice/rte_pmd_ice_version.map > > > +++ b/drivers/net/ice/rte_pmd_ice_version.map > > > +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; > > > +}; > > > > Given that you provide some functions to access to the metadata, > > why do you need to export these flags and field in the .map? > > > > However, the functions are missing in the .map. > > Did you try to compile as a shared library? > > > > These functions are 'static inline', no need to be exported in the Yes I missed they are inline. > .map. And the macros like 'PKT_RX_DYNF_PROTO_XTR_XXX', in fact, their > real definitions are global values defined in rte_pmd_ice like: > rte_net_ice_dynflag_proto_xtr_xxx_mask. > > Since rte_pmd_ice are required to compiled as a shared library, so > it is needed to export these flags and field in the .map. > > This design is referred to the below upstream practice about dynamic > mbuf. > > commit 7743e81854944ed17df05bfdcba26556cb41ca0c > Author: Viacheslav Ovsiienko > Date: Tue Nov 5 14:19:30 2019 +0000 > > ethdev: extend flow metadata > > --- a/lib/librte_ethdev/rte_ethdev_version.map > +++ b/lib/librte_ethdev/rte_ethdev_version.map > @@ -289,4 +289,7 @@ EXPERIMENTAL { > rte_eth_rx_hairpin_queue_setup; > rte_eth_tx_burst_mode_get; > rte_eth_tx_hairpin_queue_setup; > + rte_flow_dynf_metadata_offs; > + rte_flow_dynf_metadata_mask; > + rte_flow_dynf_metadata_register; > }; Yes all these internals are exported because we use macros or inline functions. Matter of tradeoff between API cleaning and performance...