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 693E7A00BE; Wed, 30 Oct 2019 16:58:03 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 632181C01B; Wed, 30 Oct 2019 16:58:02 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 9DB281C011 for ; Wed, 30 Oct 2019 16:58:00 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0A3A521C28; Wed, 30 Oct 2019 11:58:00 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 30 Oct 2019 11:58:00 -0400 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=Cy4ThHAzh/kx3LgN1oRMq6wMVjsGbLDedXFJ5KR1ECY=; b=c8WjKSH4rLj6 FefRWm6Ol5moQYWLVR9PaqqbUtGRWbmbWP0rUZg/6V8MFhY2AwxF9Q5ngVuyRNPx i0aKMOaTzlxqeEoGedaTVA6WhD1NEEubcQLAcU84Ut32cx5OeVOG5EtfdVvuh0hk 3fK2w5imG2aLSo6qD4MZOUTJrdDOYhU= 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=Cy4ThHAzh/kx3LgN1oRMq6wMVjsGbLDedXFJ5KR1E CY=; b=ivHEw9Tw8//3J0RpXqD8vr+jAe9oKQLrYEv0cMFDbzXGdttjZOm0+ngll m6tt/emJKyqwz03pvA45oshIm2fTpvOI/HtCMqgNJYpjftggLkiC9kHQWIeRyt+T B/gKs3saibmBn3WAzPPJEXIKxhRln8/yr9/AmfWxsZKNq7hHRciiJh2u7IRAR8Au ToH+p66izpMF+sEEdK/tLve99Bmx+ysIW5+Vebhve/yoZomCIjCEc0/WVhkEFCzP EgxAbqg6z7Ih05k8GAi7a5Ohs0N5G/p5PVzVbRtPIhilJL/VwEKMEBrGwfz+1pQg hedxQWDv6lORGpknlNuBt10hAdIRQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtfedgkeegucetufdoteggodetrfdotf 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 AD7E7306005C; Wed, 30 Oct 2019 11:57:58 -0400 (EDT) From: Thomas Monjalon To: Slava Ovsiienko Cc: Olivier Matz , Andrew Rybchenko , "dev@dpdk.org" , Matan Azrad , Raslan Darawsheh Date: Wed, 30 Oct 2019 16:57:56 +0100 Message-ID: <2040312.DVR5md6s3k@xps> In-Reply-To: <20191030152023.q3aubtc6u56afhvn@platinum> References: <1572201636-16374-1-git-send-email-viacheslavo@mellanox.com> <20191030152023.q3aubtc6u56afhvn@platinum> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v5] ethdev: extend flow metadata 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" 30/10/2019 16:20, Olivier Matz: > > From: Slava Ovsiienko > > > > On 10/29/19 10:31 PM, Viacheslav Ovsiienko wrote: > > > > > Currently, metadata can be set on egress path via mbuf tx_metadata > > > > > field with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_META > > > > matches metadata. > > > > > > > > > > This patch extends the metadata feature usability. > > > > > > > > > > 1) RTE_FLOW_ACTION_TYPE_SET_META > > > > > > > > > > When supporting multiple tables, Tx metadata can also be set by a > > > > > rule and matched by another rule. This new action allows metadata to > > > > > be set as a result of flow match. > > > > > > > > > > 2) Metadata on ingress > > > > > > > > > > There's also need to support metadata on ingress. Metadata can be > > > > > set by SET_META action and matched by META item like Tx. The final > > > > > value set by the action will be delivered to application via > > > > > metadata dynamic field of mbuf which can be accessed by > > > > > RTE_FLOW_DYNF_METADATA() macro or with > > > > > rte_flow_dynf_metadata_set() and rte_flow_dynf_metadata_get() helper > > > > > routines. PKT_RX_DYNF_METADATA flag will be set along with the data. > > > > > > We have a problem with PKT_RX_DYNF_METADATA/ > > > PKT_TX_DYNF_METADATA. > > > These ones are referencing to global variable > > > "rte_flow_dynf_metadata_mask". > > > And there are routines in rte_mbuf.c (rte_get_rx_ol_flag_list) which show > > > the names of flags. It is not good if rte_mbuf.c would require including of > > > rte_flow.h and linking rte_flow.c (not all apps use rte_flow or even ethdev). > > > > > > What do you think? Should we rename rte_flow_dynf_xxxxx variables to > > > rte_mbuf_dynf_flow_metadata_xxxx and put ones into the rte_mbuf_dyn.c? > > > The same about PKT_RX_DYNF_METADATA definition, is it candidate to > > > move to rte_mbuf_dyn.h ? It would allow not to link or include rte_flow.c/h > > > into rte_mbuf.c > > > > > In rte_mbuf_dyn.c, we maintain a list of registered flags. I think it > wouldn't be too difficult to introduce the equivalent of > rte_get_*_ol_flag_list() and *rte_get_*_ol_flag_name() for dynamic > flags. There is already a dump function (which does both fields and > flags), and a lookup by name function. > > Maybe we could split the dump into fields and flags, and add a lookup by > offset/bitnum. Would it work for your use-case? I think it would not be so useful. I propose to maintain the function rte_get_rx_ol_flag_list() only for static mbuf fields, and do not list the dynamic flags. In short, do nothing :)