From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 7A1CB42486;
	Wed, 25 Jan 2023 15:00:05 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 60D8A42D47;
	Wed, 25 Jan 2023 15:00:05 +0100 (CET)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com
 [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id C0FC042D3E
 for <dev@dpdk.org>; Wed, 25 Jan 2023 15:00:03 +0100 (CET)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43])
 by mailout.nyi.internal (Postfix) with ESMTP id 5D8645C00F2;
 Wed, 25 Jan 2023 09:00:02 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
 by compute3.internal (MEProxy); Wed, 25 Jan 2023 09:00:02 -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=1674655202; x=
 1674741602; bh=EA/3DLPHWIZnkkjIG31csCNcPoAJBZn3u0Fn8lX0rL8=; b=a
 Fz7rj5duT3TvAGGvEYjQwF9NguYFaY1UWuDsbBmPbFV2GgJzHcjSVzT0jKo/a0wM
 B3BwgYaqwAMUKGF+ABgu9ya5kfH3y89fdmnV0W07ft5o5IzpAZolC/ikX4rptCu8
 uXhyHVKtgz4F5gLmSEulJ9jLdbes2cp58+7qE5LtRKA8eW0drdBaI1f8UFnWO0ie
 oSEy3UwqT9gRNneDpQROFK/Ufr8DHoGscoWZyCklsg7iKrUpsDyAJo/h/ejEXIKD
 E4cttURGtNHS/itUxn6KzvE1zmWprLMEhGjqDW89wL3lIxJagcEmMGb8mhvPFGRS
 a3Yd2KVynK+EhfxVI51EQ==
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=1674655202; x=
 1674741602; bh=EA/3DLPHWIZnkkjIG31csCNcPoAJBZn3u0Fn8lX0rL8=; b=a
 GeRkCMycZ1D847CF4ZM+rsI8E3yWfO6cq6FxiK3VLTgbGoB7FB1QhypEhU/B8JcF
 RzE68pg16ig15nkTXCBc3koV26p6BMm60UsrnazwUbnyOyPqeZvUg1bw7OG/yuAB
 poeeKfUhdrKf07mX87GcJtVKza6nRELAIUJD6XOhE+uIZPB27AdtpAFY6UbDxY7x
 FwzyP9+9aFTwdNR40lpU9XVqKtKUTKJAohzvAKDO8dR9nMX3B6v5q3WjgjI/E/w0
 rtdvZg1lLtQxtNyBBbDR4rmSpvM4Ggh31mf3n2e8ivSlbl4HmXaEGLMlcDc7axXa
 749vfUBZtvvwPzyAkTovA==
X-ME-Sender: <xms:4jXRY9ByAEVTkt8tMrIHix1ISw41xS2tviZOKMvGB-l_on0vTl3PWg>
 <xme:4jXRY7jeDUgfkDCNSEDydFcc_k8LN-IQJhFgJ5XVD5EM1nsUgt4kQC_1uAvP9ujF3
 CcE-Cr1R9IeNgEz0g>
X-ME-Received: <xmr:4jXRY4l8Af0K2YJHr9H6bg3cbC46Q8v4W8vg6QddUljaJ6EBKeNk0Dds36vvxD5tFK_CGSiBRXTa6tksoCzpxWzbTg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddvvddgheekucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm
 rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc
 ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei
 kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh
 hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght
X-ME-Proxy: <xmx:4jXRY3yItPCGPdC9tOOUyPL93m8Hms7IscoEjCa9b1_5R50mW60vQA>
 <xmx:4jXRYyRJEUYMuZ5uVFW2ep9CUV-5m8NjMh_juVXmOQdW6LdRt_fKgA>
 <xmx:4jXRY6YYKYNpqxstTZN7vvXPMxDMWBD8kNV6_JVP8E6G9WWpIH-JCw>
 <xmx:4jXRYz_ALPzZIL1X-snsXJZ21XfL9xjUEtza2cgP-zTNG9k-cvGS0Q>
Feedback-ID: i47234305:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 25 Jan 2023 09:00:00 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
To: Aman Singh <aman.deep.singh@intel.com>,
 Yuying Zhang <yuying.zhang@intel.com>, Ivan Malov <ivan.malov@oktetlabs.ru>,
 Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>, dev@dpdk.org,
 Hanumanth Reddy Pothula <hpothula@marvell.com>,
 Ferruh Yigit <ferruh.yigit@amd.com>
Cc: "viacheslavo@nvidia.com" <viacheslavo@nvidia.com>,
 Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
 Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>, david.marchand@redhat.com
Subject: Re: [EXT] Re: [PATCH v5 2/2] app/testpmd: add command to process Rx
 metadata negotiation
Date: Wed, 25 Jan 2023 14:59:59 +0100
Message-ID: <2252130.NnIJQXNAa5@thomas>
In-Reply-To: <aa260e84-f433-590e-4423-ce7de52aab32@amd.com>
References: <20221220200250.2413443-1-hpothula@marvell.com>
 <5290135.upeRZZJTqa@thomas>
 <aa260e84-f433-590e-4423-ce7de52aab32@amd.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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

25/01/2023 14:55, Ferruh Yigit:
> On 1/25/2023 12:55 PM, Thomas Monjalon wrote:
> > 25/01/2023 10:30, Hanumanth Reddy Pothula:
> >> ++ Ivan Malov and Andrew Rybchenko
> >>
> >> From: Ferruh Yigit <ferruh.yigit@amd.com>
> >>> On 12/21/2022 2:07 AM, Hanumanth Pothula wrote:
> >>>> Presently, Rx metadata is sent to PMD by default, leading to a
> >>>> performance drop as processing for the same in Rx path takes extra
> >>>> cycles.
> >>>>
> >>>> Hence, add new testpmd command,
> >>>>   'enable port <port_id> nic_to_pmd_rx_metadata'
> >>>>
> >>>> This command helps in sending Rx metadata to PMD and thereby Rx
> >>>> metadata flow command requests are processed.
> >>>>
> >>>> Signed-off-by: Hanumanth Pothula <hpothula@marvell.com>
> >>>
> >>> Hi Hanumanth,
> >>>
> >>> I agree with Thomas for the patch.
> >>>
> >>> 'eth_rx_metadata_negotiate_mp()' requests all Rx metadata offloads to be
> >>> enabled, but at this stage if there is no flow rule for Rx metadata why it is
> >>> consuming extra cycles?
> >>>
> >>> Can you update driver code to process Rx metadata when it is enabled by
> >>> application (via 'rte_eth_rx_metadata_negotiate()') AND there is at least
> >>> one flow rule for it?
> >>
> >> #1 What is the purpose of rte_eth_rx_metadata_negotiate() API if it is always called by testpmd.
> >> We thought it was added so that when that metadata is not needed, application need not call this
> >> thereby saving cycles/bandwidth.
> > 
> > testpmd is for testing all features. That's why all is negotiated.
> > Cycles should be saved if you don't enable it until a flow rule requires it.
> > 
> 
> Hi Thomas,
> 
> Not just for saving cycles, but from testing perspective too, do you
> think does it work if a way to disable these Rx metadata added by
> keeping default behavior as it is?
> 
> And new command can be in a consistent command syntax like:
> "port config <port_id> ..."

Yes I agree it would be good to have a way to test different values.
And it would allow to completely disable metadata I suppose.

Note: I don't understand why we don't have
RTE_FLOW_ACTION_TYPE_SET_TAG and RTE_FLOW_ACTION_TYPE_SET_META
negotiated in this function. Probably something to add.


> >> #2 We use this API similar to Rx/Tx offload flags so that we can set things up before device is
> >> configured. We thought that is the purpose of having this negotiate API and avoid depleting offload flags.
> > 
> > It is just a configuration negotiation specific to metadata.
> > 
> >> #3 Generally any new offloads added to DPDK would be in disabled state in testpmd and we would have
> >> an option to enable it. In this case, testpmd is by default calling this negotiation.
> > 
> > Negotiating is not enabling.
> > 
> >> We can update the driver if the purpose of this API is clear.
> > 
> > Please do.
> 
> Is following understanding correct?
> 
>      API        Flow Rule       Result
>     -----    ------------     --------
>     Enable    No Rule	       Feature Disabled
>     Enable    Rule exist       Feature Enabled
>     Disable     X              Feature Disabled

In the API column, you should say "negotiated" instead of "Enable".