From: Stephen Hemminger <stephen@networkplumber.org>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: "fengchengwen" <fengchengwen@huawei.com>, <dev@dpdk.org>,
"Aman Singh" <aman.deep.singh@intel.com>,
"Thomas Monjalon" <thomas@monjalon.net>,
"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>,
"Ivan Malov" <ivan.malov@arknetworks.am>,
"Konstantin Ananyev" <konstantin.ananyev@huawei.com>
Subject: Re: [PATCH v3 1/3] testpmd: Do not enable mbuf fast release TX offload by default
Date: Tue, 5 Aug 2025 08:48:36 -0700 [thread overview]
Message-ID: <20250805084836.0d68f4af@hermes.local> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9FDFF@smartserver.smartshare.dk>
On Tue, 5 Aug 2025 07:48:41 +0200
Morten Brørup <mb@smartsharesystems.com> wrote:
> > From: fengchengwen [mailto:fengchengwen@huawei.com]
> > Sent: Tuesday, 5 August 2025 02.59
> >
> > On 8/4/2025 3:42 AM, Morten Brørup wrote:
> > > Enabling some offload by default may conflict with a manually
> > configured
> > > offload.
> > > Specifically, the mbuf fast release TX offload, which conflicts with
> > multi
> > > segment packet TX offload, was enabled by default.
> > > Therefore, mbuf fast release TX offload (the only TX offload which was
> > > enabled by default) is not enabled by default anymore.
> >
> > This may impact default performance, many vendor performance report has
> > testpmd iofwd or macfwd case.
>
> Yes.
>
> IMO, any optimizations, mbuf-fast-free or mbuf-recycle, must be explicitly enabled, and documented in the performance reports when used.
> Otherwise the performance reports give a false impression of higher performance, which is only available under certain circumstances.
> I have complained about this before.
> Which is also why mbuf-recycle must be explicitly enabled.
> With this patch, the same finally applies to mbuf-fast-free too.
> I could add a Fixes tag, but I think it is better to categorize this patch as an improvement rather than a bug fix.
>
Agree that optimizations like this need to be opt-in.
Maybe ethdev should automatically downgrade rather than reject bad configurations.
The DPDK already has too many "benchmark special" tweaks.
next prev parent reply other threads:[~2025-08-05 15:48 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-31 9:07 [PATCH] ethdev: Reject conflicting TX offloads configuration Morten Brørup
2025-07-31 9:24 ` Bruce Richardson
2025-07-31 10:07 ` Andrew Rybchenko
2025-07-31 9:27 ` Ivan Malov
2025-07-31 9:34 ` Morten Brørup
2025-07-31 11:32 ` Konstantin Ananyev
2025-07-31 12:56 ` [PATCH v2 1/3] testpmd: Do not enable mbuf fast release TX offload by default Morten Brørup
2025-07-31 12:56 ` [PATCH v2 2/3] ethdev: Improve descriptions of RX and TX offloads Morten Brørup
2025-07-31 12:56 ` [PATCH v2 3/3] ethdev: Reject conflicting TX offloads configuration Morten Brørup
2025-08-01 1:09 ` zhoumin
2025-08-02 20:53 ` [PATCH] " Stephen Hemminger
2025-08-02 21:33 ` Ivan Malov
2025-08-03 10:51 ` Morten Brørup
2025-08-03 15:56 ` Stephen Hemminger
2025-08-03 19:42 ` [PATCH v3 1/3] testpmd: Do not enable mbuf fast release TX offload by default Morten Brørup
2025-08-03 19:42 ` [PATCH v3 2/3] ethdev: Improve descriptions of RX and TX offloads Morten Brørup
2025-09-15 17:48 ` Stephen Hemminger
2025-08-03 19:42 ` [PATCH v3 3/3] ethdev: Reject conflicting TX offloads configuration Morten Brørup
2025-08-05 2:10 ` fengchengwen
2025-08-05 13:11 ` Morten Brørup
2025-08-05 0:58 ` [PATCH v3 1/3] testpmd: Do not enable mbuf fast release TX offload by default fengchengwen
2025-08-05 5:48 ` Morten Brørup
2025-08-05 7:08 ` Ivan Malov
2025-08-05 15:48 ` Stephen Hemminger [this message]
2025-08-11 8:17 ` Morten Brørup
2025-08-11 8:41 ` Ivan Malov
2025-08-11 9:26 ` Andrew Rybchenko
2025-08-11 9:03 ` Konstantin Ananyev
2025-08-11 11:47 ` fengchengwen
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=20250805084836.0d68f4af@hermes.local \
--to=stephen@networkplumber.org \
--cc=aman.deep.singh@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=ivan.malov@arknetworks.am \
--cc=konstantin.ananyev@huawei.com \
--cc=mb@smartsharesystems.com \
--cc=thomas@monjalon.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.