From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D0057A00BE; Mon, 14 Mar 2022 21:42:55 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 64142410E7; Mon, 14 Mar 2022 21:42:55 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 84DFE40E2D for ; Mon, 14 Mar 2022 21:42:54 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 18BE05C0219; Mon, 14 Mar 2022 16:42:54 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 14 Mar 2022 16:42:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; bh=H3a1EjqCi9gTyq T/qrk4NwmnKLUu/74mu7ww/CXYpWU=; b=hOkjzk2xa04FqUJj3B8bRn92AtGBbu hKv/WCZdVzjBE1wFBSW49b2xQHKuLQE/TI8Qj97H3KWM5o70ELsF2FPDsPi7sJ2G 0s7rq8d8Wtm2vX0YRkc2CmEj2bkUZ8Ip3A+kiEGKtAKsAmZ7B8TO+amlULdenFJM e60Lps9WzAvLEtbYfnGiZBNrpsvVw7bw2QtrLJ/cbWuaw2fig5bRcUPvAa42AhBV YXJTOqCyPFaxQgqWNR9t9YygRER83H9qVmRcvN9yNCGrEdF+x6z9T8q6ayUVL/eZ 6C1kBUcHOyYq0j/Jz5gI+xSMxPU7hIvi2Zuy/UyOzTEqGVVZWdC2tTkg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=H3a1EjqCi9gTyqT/qrk4NwmnKLUu/74mu7ww/CXYp WU=; b=HVomN0JN72xF3W1HVDPenenPtajYUZ9A2I4uJfsDec5DRpL0f8DjTh/el y2VBMFA2/d5o6Cm9rSigPVlUDElm4of9feNBy79N6JjswevoUDSVowQp5EZhsFYc qx5WpJWrOr1bl2mWc9qL7MlPpLqEH+/JJsgdhnEBer1l2oWV3ywRAvSxEsSLmuWi 5RUd5F0fcD0XJTpQfS7dok7Mh+wNrNqYliZDyDUPHhjBXP8V/Tv2ZIypL0gg3O30 lClNnEy+NmJyr6nwiEF4o2UKX4eOptb9/+LKiQIIQHl8vBqvQYlr/zeIzs4nCMSB sUGz0b4qOM6/asK31JH5rBIP6koaQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddvkedgudefkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 14 Mar 2022 16:42:52 -0400 (EDT) From: Thomas Monjalon To: Dariusz Sosnowski Cc: Ferruh Yigit , Ori Kam , Xiaoyun Li , Aman Singh , Yuying Zhang , dev@dpdk.org, Slava Ovsiienko Subject: Re: [PATCH] app/testpmd: register metadata dynfield on modify field Date: Mon, 14 Mar 2022 21:42:51 +0100 Message-ID: <4790656.0VBMTVartN@thomas> In-Reply-To: References: <20220301115113.306497-1-dsosnowski@nvidia.com> <254404e0-2882-3eff-2820-74063660a23b@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 09/03/2022 12:50, Dariusz Sosnowski: > From: Ferruh Yigit > > On 3/1/2022 11:51 AM, Dariusz Sosnowski wrote: > > > This patch adds implicit registration of metadata dynamic field and > > > flag > > > > Hi Dariusz, > > > > metaday dynamic field is explicitly registered when testpmd command used > > to enable tx metadata, or rte flow rule created with "set_meta" action. > > > > Can you please document more when this implicit enablement is required? > > And why that case doesn't cover above explicit enable cases? > > Before this patch, when a user inserted a flow rule with MODIFY_FIELD action, > which modified packet metadata, the metadata dynamic field was not registered, as opposed to > what happened with SET_META action. Goal of this patch is to make the behavior consistent > between these two actions. I think consistency should be ensured by the PMD. Why not registering the field in the PMD?