From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Jerin Jacob <jerinjacobk@gmail.com>,
Thomas Monjalon <thomas@monjalon.net>
Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Ori Kam <orika@nvidia.com>,
Ivan Malov <ivan.malov@arknetworks.am>,
Nithin Kumar Dabilpuram <ndabilpuram@marvell.com>,
Aman Singh <aman.deep.singh@intel.com>,
Yuying Zhang <yuying.zhang@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
Hanumanth Reddy Pothula <hpothula@marvell.com>,
Slava Ovsiienko <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, 1 Feb 2023 11:35:50 +0000 [thread overview]
Message-ID: <22a65100-bee8-1726-6e27-14b9028a29d4@amd.com> (raw)
In-Reply-To: <CALBAE1NKX5Y_inh_qSe_r5MBLpAg-VEmR+TSif6wP51QLPZ2VA@mail.gmail.com>
On 2/1/2023 11:15 AM, Jerin Jacob wrote:
> On Wed, Feb 1, 2023 at 4:35 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>
>> 01/02/2023 11:58, Andrew Rybchenko:
>>> On 2/1/23 13:48, Jerin Jacob wrote:
>>>> On Wed, Feb 1, 2023 at 2:59 PM Andrew Rybchenko
>>>> <andrew.rybchenko@oktetlabs.ru> wrote:
>>>>> Frankly speaking I don't understand why default value is so
>>>>> important if we have a way to change it. Reasons should be
>>>>> really strong to change existing defaults.
>>>>
>>>> The only reason is, typically testpmd will be used performance
>>>> benchmarking as an industry standard. It is difficult to tell/educate
>>>> the QA or customers
>>>> that, "BTW if you need to get better performance add more flag to
>>>> testpmd command line".
>>
>> I disagree.
>> When you do performance benchmark, you tune settings accordingly.
>
> IMO, We tune the system resources like queue depth not the disabling
> features for raw performance.
> queue depth etc people know to tune so it is obvious. What is not
> obvious is, testpmd only
> negotiated some features by default.I am not using that feature, hence
> I need to explicitly
> disable it.
>
When 'rte_eth_rx_metadata_negotiate()' API is NOT used at all, and I
believe that is the case for almost all applications since API is a
relatively new one, PMD default behavior should be to enable Rx metadata
flow rules, in case user requests them later.
So, enabling all in application is same with not calling the API at all.
In this perspective, disabling Rx metadata is additional
optimization/tuning that application can do if it is sure that Rx
metadata flow rules won't be used at all.
And API is more meaningful when it is used to disable Rx metadata.
I think it is reasonable to enable all Rx metadata by default in testpmd
with a capability to disable it when wanted.
OR
May be we don't call 'rte_eth_rx_metadata_negotiate()' API by default in
testpmd, it is only called when it is requested explicitly from user,
enable or disable.
>
>>
>>>> To make that worst, only some PMD needs to give the additional
>>>> parameter to get better number.
>>>> And also, testpmd usage will be treated as application modeling.
>>>>
>>>> Since this feature only used on sfc and cnxk driver, What is the
>>>> situation with sfc driver?
>>>> Keeping it as negotiated and not use the feature, will impact the per
>>>> core performance of sfc or
>>>> is it just PCI bandwidth thing which really dont show any difference in testpmd?
>>>
>>> Yes, sfc could run faster if no Rx metadata are negotiated. So,
>>> it is better to negotiate nothing by default. But it is always
>>> painful to change defaults. You need to explain that now you
>>> need to negotiate Rx metadata to use mark, flag and tunnel offloads.
>>> Yes, it will be required on sfc and cnxk only.
>>> As an sfc maintainer I don't mind to change testpmd defaults.
>>
>> If we change testpmd defaults to "do nothing",
>> then we should disable MBUF_FAST_FREE as well.
>
> if you see MBUF_FAST_FREE, it does nothing. Actually,
> !MBUF_FAST_FREE is doing more work.
>
>
>>
>>
next prev parent reply other threads:[~2023-02-01 11:36 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
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 [this message]
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=22a65100-bee8-1726-6e27-14b9028a29d4@amd.com \
--to=ferruh.yigit@amd.com \
--cc=aman.deep.singh@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=hpothula@marvell.com \
--cc=ivan.malov@arknetworks.am \
--cc=jerinj@marvell.com \
--cc=jerinjacobk@gmail.com \
--cc=ndabilpuram@marvell.com \
--cc=orika@nvidia.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).