From: Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>
To: Thomas Monjalon <thomas@monjalon.net>,
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" <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>,
"david.marchand@redhat.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:42:41 +0000 [thread overview]
Message-ID: <MW2PR18MB2171AD1BE4445AD2859935A4AFCE9@MW2PR18MB2171.namprd18.prod.outlook.com> (raw)
In-Reply-To: <2252130.NnIJQXNAa5@thomas>
> >Will it work to enable them all by default and add capability to disable
> >it in testpmd, which helps to run performance tests also to verify the
> > impact of the API?
The spirit of the negotiating features/Rx/Tx offloads upfront is to have it disabled by default and enable the feature only when needed. Having the features enabled by default is probably against that spirit.
We understand the concerns with drivers that didn't not implement that API.
Why not disable it by default(like other offloads) and modify rte_flow action creation in testpmd to check for if !ENOSUP and feature disabled and add print to enable. So for the PMD's that won't support rte_eth_rx_metadata_negotiate(), there won't be any difference and for very few PMD's that support this API, they need to enable it before using RTE_FLOW with MARK/FLAG.
Behavior change would be seen only with two PMD's(cnxk, sfc).
> 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.
The purpose of negotiate is to tell the PMD upfront so that PMD can prepare
HW appropriately. Having these new actions would be very late to inform PMD and
I think won't solve the purpose.
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, January 25, 2023 7:30 PM
> 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; 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
>
> 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".
>
>
next prev parent reply other threads:[~2023-01-25 14:42 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-01 4:41 [PATCH] app/testpmd: add command line argument 'rx-metadata' Hanumanth Pothula
2022-08-01 13:11 ` Hanumanth Pothula
2022-08-01 13:13 ` Hanumanth Pothula
2022-08-01 19:41 ` Ivan Malov
2022-08-02 16:45 ` [PATCH] app/testpmd: add command line argument 'nic-to-pmd-rx-metadata' Hanumanth Pothula
2022-08-02 16:45 ` [PATCH v2 1/2] version: 22.11-rc0 Hanumanth Pothula
2022-08-02 16:45 ` [PATCH v2 2/2] app/testpmd: add command line argument 'nic-to-pmd-rx-metadata' Hanumanth Pothula
2022-08-02 17:51 ` [PATCH v2 1/1] " Hanumanth Pothula
2022-08-30 12:36 ` Hanumanth Reddy Pothula
2022-09-01 8:03 ` Singh, Aman Deep
2022-10-04 14:48 ` Andrew Rybchenko
2022-10-06 18:35 ` [PATCH v3 1/1] app/testpmd: control passing Rx metadata to PMD Hanumanth Pothula
2022-10-17 8:32 ` Andrew Rybchenko
2022-10-27 7:34 ` Thomas Monjalon
2022-10-27 12:54 ` Thomas Monjalon
2022-12-02 16:14 ` [EXT] " Hanumanth Reddy Pothula
2022-12-02 19:41 ` Thomas Monjalon
2022-12-05 7:59 ` Hanumanth Reddy Pothula
2022-12-05 8:28 ` Thomas Monjalon
2022-12-05 9:43 ` Slava Ovsiienko
2022-12-20 20:02 ` [PATCH v4 1/2] ethdev: control Rx metadata negotiation Hanumanth Pothula
2022-12-20 20:02 ` [PATCH v4 2/2] app/testpmd: add command to process " Hanumanth Pothula
2022-12-20 21:23 ` Stephen Hemminger
2022-12-21 2:07 ` [PATCH v5 1/2] ethdev: fix ethdev configuration state on reset Hanumanth Pothula
2022-12-21 2:07 ` [PATCH v5 2/2] app/testpmd: add command to process Rx metadata negotiation Hanumanth Pothula
2023-01-18 10:32 ` Thomas Monjalon
2023-01-19 10:33 ` [EXT] " Hanumanth Reddy Pothula
2023-01-25 12:51 ` Thomas Monjalon
2023-01-24 18:04 ` Ferruh Yigit
2023-01-25 9:30 ` [EXT] " Hanumanth Reddy Pothula
2023-01-25 12:55 ` Thomas Monjalon
2023-01-25 13:55 ` Ferruh Yigit
2023-01-25 13:59 ` Thomas Monjalon
2023-01-25 14:42 ` Nithin Kumar Dabilpuram [this message]
2023-01-26 11:03 ` Thomas Monjalon
2023-01-27 5:02 ` Nithin Kumar Dabilpuram
2023-01-27 8:54 ` Thomas Monjalon
2023-01-27 10:42 ` Nithin Kumar Dabilpuram
2023-01-27 15:01 ` Thomas Monjalon
2023-01-31 16:17 ` Jerin Jacob
2023-01-31 23:03 ` Thomas Monjalon
2023-02-01 6:10 ` Ivan Malov
2023-02-01 7:16 ` Andrew Rybchenko
2023-02-01 8:53 ` Jerin Jacob
2023-02-01 9:00 ` Ori Kam
2023-02-01 9:05 ` Thomas Monjalon
2023-02-01 9:07 ` Andrew Rybchenko
2023-02-01 9:14 ` Jerin Jacob
2023-02-01 9:29 ` Andrew Rybchenko
2023-02-01 10:48 ` Jerin Jacob
2023-02-01 10:58 ` Andrew Rybchenko
2023-02-01 11:04 ` Thomas Monjalon
2023-02-01 11:15 ` Jerin Jacob
2023-02-01 11:35 ` Ferruh Yigit
2023-02-01 13:48 ` Jerin Jacob
2023-02-01 14:50 ` Ferruh Yigit
2023-02-01 15:22 ` Jerin Jacob
2023-02-02 8:43 ` Ferruh Yigit
2023-02-02 8:50 ` Ivan Malov
2023-02-02 9:17 ` Ferruh Yigit
2023-02-02 10:41 ` Ivan Malov
2023-02-02 10:48 ` Ivan Malov
2023-02-02 11:41 ` Thomas Monjalon
2023-02-02 11:55 ` Ivan Malov
2023-02-02 12:03 ` Thomas Monjalon
2023-02-02 12:21 ` Andrew Rybchenko
2023-02-01 11:20 ` Ivan Malov
2023-01-25 13:17 ` Ferruh Yigit
2023-01-25 13:21 ` Ferruh Yigit
2023-01-25 13:21 ` Ferruh Yigit
2023-01-16 10:43 ` [PATCH v5 1/2] ethdev: fix ethdev configuration state on reset Hanumanth Reddy Pothula
2023-01-18 10:29 ` Thomas Monjalon
2023-01-24 18:14 ` Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MW2PR18MB2171AD1BE4445AD2859935A4AFCE9@MW2PR18MB2171.namprd18.prod.outlook.com \
--to=ndabilpuram@marvell.com \
--cc=aman.deep.singh@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=hpothula@marvell.com \
--cc=ivan.malov@oktetlabs.ru \
--cc=jerinj@marvell.com \
--cc=thomas@monjalon.net \
--cc=viacheslavo@nvidia.com \
--cc=yuying.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).