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 72B5DA04B4; Fri, 8 Nov 2019 15:40:05 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 313471C1E0; Fri, 8 Nov 2019 15:40:05 +0100 (CET) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id 8CC811C0B5 for ; Fri, 8 Nov 2019 15:40:03 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 5D4BF4B6; Fri, 8 Nov 2019 09:40:02 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 08 Nov 2019 09:40:02 -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=AJt+NKEYjIuQUl8s9OcA0iM93AGeqo1rPNxWbZ3//5o=; b=SnpRcshQUes2 +ct3ATImk55EmheqOjCaNIaqTT+IzBYAMibwRroAAKt3o88uEDTL9qKjDQ8L2gnY xUS1uZg3bhsg6dXOvO0gbEgyb3r+3Qvpf66grN8BFBDcIKi5fFF97Mo2LppeX5nt xds+3EpeOP+lyalyLfK0uq/L4akf15Q= 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=AJt+NKEYjIuQUl8s9OcA0iM93AGeqo1rPNxWbZ3// 5o=; b=t86eQ4zrpLSCGn7nNKj1Y/AVI0S/mzB52/m56SBb1w6l8ki7w0/UTeQDy KFJT443bzIXwMXmxUTdiRBBO5AT17sBATE8RfaPwVQ/fHWuhXSnjqyNS8AQk3dY4 SPPJ7vfFSWcrnujTbpRvbLsy5HfurjwE3woI5hbhE5w6nGcn+tXFxjG21kyzxGk+ voMduozgtkSZqMPzYOoIeyGNmkfmV6Z0v2LuJieW5s9YntOEbTBUkFhJ/Eme2NPm GjoxkrWATqeAgrQr+ifiyvpS671+H+/tFjHyivbZbPD106uyFTovmYl4HthDNe+X Y4K7k1BsfKgDrkObqp+ii2euteG+w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddvuddgieekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt 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 61FB680061; Fri, 8 Nov 2019 09:39:59 -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:39:58 +0100 Message-ID: <2644972.cy8Zfzkded@xps> In-Reply-To: References: <20191105011918.53434-1-haiyue.wang@intel.com> <1962515.WBHSJCFqR1@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: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 extraction 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 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 > > > > Yes using a dynamic field is definitely more correct. > > > > > type and validity is indicated by related bit in 'rte_mbuf::ol_flags'. > > > > 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 prior 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 metadata, 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_" ? I started to do such change a long time ago and never finished. Yes it will be changed for 20.11. > Or keep the above as it is now, to keep the same ol_flags style, until all > the "PKT_RX_" are changed ? Please I prefer you change yours, without waiting global change.