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 4C7A6A04AB; Fri, 8 Nov 2019 13:34:34 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B539A1C12A; Fri, 8 Nov 2019 13:34:32 +0100 (CET) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by dpdk.org (Postfix) with ESMTP id 58A4E1C129 for ; Fri, 8 Nov 2019 13:34:31 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id BDC18469; Fri, 8 Nov 2019 07:34:28 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 08 Nov 2019 07:34:29 -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=UP/mwmnn99mxVKFdOVaofl/1E3vPZ0FSUheDmkUj6l0=; b=kCyH/1Vu5RQE KxnIn85fydPHKOTZaLk95YUFpQbBlWcDeu/Ut9IxByMVfcc8K4GgSfnj0DPSQwEr 1rrQUSH8ghUolC1DbnZe+5bHbWiVUG4MwMrtvwW8qk9mi9sIs+NqF8QX9p9Stt61 dPcn1EI5cPdSAfyZ7r0WHygH59XcDUU= 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=UP/mwmnn99mxVKFdOVaofl/1E3vPZ0FSUheDmkUj6 l0=; b=jAJ924zKQEUJoOE3MOx62HJVRziii0OliYqIbrSKAQKBI/ieg8BZJ23BW CknVIf+kIPUQ0DuHgH+eWsJgozrFZqxyFhUYspXNdSAxEPrpXkBrS/7zKYhh745X gRYuYueCbBm3VY3iDiYY8IaT8uvru2FR4fhJkFrSE8YbGXMVij9Cd+69Ztw7biZv TJin4DQlKeLSuO8TAFpDYxlMBp7ipCBO3anL6rKEOmRxC+SD96Y3k/ictgh1sdJB QTyRfi6oQhS5WX5GqKKGjVtNf6tb3gEdIUhCdgD6agI4yz5OU3Uxpw0kwbT2mc6o nxI5oUhli2aTj3vA2ODgrKGeK8Q3w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddvuddggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeelfedrvdefrddutdegrdduudeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (118.104.23.93.rev.sfr.net [93.23.104.118]) by mail.messagingengine.com (Postfix) with ESMTPA id 80622306005E; Fri, 8 Nov 2019 07:34:26 -0500 (EST) From: Thomas Monjalon To: Haiyue Wang Cc: dev@dpdk.org, olivier.matz@6wind.com, xiaolong.ye@intel.com, ferruh.yigit@intel.com Date: Fri, 08 Nov 2019 13:34:23 +0100 Message-ID: <1962515.WBHSJCFqR1@xps> In-Reply-To: <20191107104402.99398-1-haiyue.wang@intel.com> References: <20191105011918.53434-1-haiyue.wang@intel.com> <20191107104402.99398-1-haiyue.wang@intel.com> 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" 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. > --- 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. [...] > +/** > + * 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)