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 7DA7841B93; Wed, 1 Feb 2023 00:03:19 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5ADED40DFB; Wed, 1 Feb 2023 00:03:19 +0100 (CET) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 9528940A8B for ; Wed, 1 Feb 2023 00:03:18 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 5C7E83200645; Tue, 31 Jan 2023 18:03:16 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 31 Jan 2023 18:03:17 -0500 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=fm3; t=1675206195; x= 1675292595; bh=QO5UTRbKYQQ9ZV5SVAC8vvLikeZ7Ll8p9lQfyQt+Hoo=; b=B C3d78cMM+O9qGhWM5DhZLHScXYJZzeyrZcGJBD/K7ina2yV5YPfjp3NQS9ZM12Kr 0f7DnB+s3fqugCFYJmVF5jgIHiTqIe/LazSKQrkwQ0SDgGZklC8y9hqNC/qFKNR/ Ebzd94Ktzr0BxpqvtwsVpcduNmG71o952zhXf/FfvzQ8jJchuQCJfAQF7QF4RK1j IYQ2ZyljovcK+s122aIYP4AtzuitPqBHACkglTKF3gMx8WRKPe87pFv1irfbzR3z qF7AAeF46DiB5cmQ4OJvGNcGc/vJcCsGWpjlPEs30gR+Y/hXSAId2Cu7XwihQt2Z VbZ1S3aml+sLRCIMOii+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id: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=fm3; t=1675206195; x= 1675292595; bh=QO5UTRbKYQQ9ZV5SVAC8vvLikeZ7Ll8p9lQfyQt+Hoo=; b=J p7A2WrhfwtI3hp3atwW9Rln2/ToGnw9El12m82hvsib+n3jhw8nwW72Omk4kn/r0 qs7x1YnpZMwckNd85FpPcl//qUiKbvrOpsKdvqC/G6DgxET4Oep/u8eBN8JDK9AD rzguMxYvqUFoSPF3jRnDDsPKzrSj++2D30qfkLy7FsaU7eV6JKjSQXri4jwuTLmV nVG7cQqf7vDxhD8Yz/H/D+hiP3w85v1YTksGv58iFsZAk20qfK3AtqAIkQJUl8bY z2NB/0f7YMWo7x9c7iNGn5BzuOI2UWW3bZRYLxAMUx6s9lq7TZS+jzOYo4/EAtr3 BP3/8SmhuQPeY5DrRiiqw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefhedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 31 Jan 2023 18:03:14 -0500 (EST) From: Thomas Monjalon To: Ivan Malov , Andrew Rybchenko , Ferruh Yigit , orika@nvidia.com, Ivan Malov Cc: Jerin Jacob , Nithin Kumar Dabilpuram , Aman Singh , Yuying Zhang , "dev@dpdk.org" , Hanumanth Reddy Pothula , "viacheslavo@nvidia.com" , Jerin Jacob Kollanukkaran , "david.marchand@redhat.com" Subject: Re: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation Date: Wed, 01 Feb 2023 00:03:11 +0100 Message-ID: <837604649.0ifERbkFSE@thomas> In-Reply-To: References: <20221220200250.2413443-1-hpothula@marvell.com> <13375798.lhuNh5TYOU@thomas> 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 31/01/2023 17:17, Jerin Jacob: > On Fri, Jan 27, 2023 at 8:31 PM Thomas Monjalon wrote: > > > > 27/01/2023 11:42, Nithin Kumar Dabilpuram: > > > From: Thomas Monjalon > > > > 27/01/2023 06:02, Nithin Kumar Dabilpuram: > > > > > From: Thomas Monjalon > > > > > > Ferruh is proposing to have a command "port config ..." > > > > > > to configure the flags to negotiate. > > > > > > Are you OK with this approach? > > > > > > > > > > Yes, we are fine to have such command to enable and disable the feature > > > > > with default being it disabled if supported by PMD. > > > > > Is default being disabled fine if the feature is supported by a PMD ? > > > > > > > > I think the default should be enabled for ease of use. > > > > > > Since testpmd is used extensively for benchmarking purposes, we thought it should have minimum features > > > enabled by default. The default testpmd doesn't have any Rx/Tx offloads enabled(except for FAST FREE), default > > > fwd mode being "iofwd" and the Rx metadata is only referenced when dumping packets. > > > > > > > > > > Do we have similar features disables by default? > > > > I mean do we know features in testpmd which require a "double enablement" > > > > like one configuration command + one rte_flow rule? > > > > > > Spec itself is that way i.e "RTE_FLOW_RULE + RX_METADATA_NEGOTIATE(once)" > > > > > > Isn't it enough if > > > > > > #1 We have enough print when rte_flow is being create without negotiation done and ask user to enable rx metadata using > > > "port config ..." > > > #2 Provide testpmd app arg to enable Rx metadata(for example " --rx-metadata") like other features to avoid calling another > > > command before rte flow create. > > > > I'm not sure what is best. > > I will let others discuss this part. > > IMO, enabling something always defeat the purpose to negotiate. IMO, > someone needs to negotiate > for a feature if the feature is needed. I think, the double enablement > is part of the spec itself. In case, The PMD > drivers won't like double enablement, no need to implement the PMD > callback. That way, there is no change in the existing flow. > > The reason why cnxk driver thought of leveraging negotiate() feature > so that it helps for optimization. e.s.p > function template for multiprocess case as we know what features > needed in fastpath upfront. > > If there still concerns with patch we can take up this to TB decide > one way or another to make forward progress. Let us know. Ferruh, Andrew, Ori, Ivan, what is your opinion? Let's progress with this patch to make it in -rc1.