From: Stephen Hemminger <stephen@networkplumber.org>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: "Ajit Khaparde" <ajit.khaparde@broadcom.com>,
"Somnath Kotur" <somnath.kotur@broadcom.com>,
"Nithin Dabilpuram" <ndabilpuram@marvell.com>,
"Kiran Kumar K" <kirankumark@marvell.com>,
"Sunil Kumar Kori" <skori@marvell.com>,
"Satha Rao" <skoteshwar@marvell.com>,
"Harman Kalra" <hkalra@marvell.com>,
"Hemant Agrawal" <hemant.agrawal@nxp.com>,
"Sachin Saxena" <sachin.saxena@oss.nxp.com>,
"Shai Brandes" <shaibran@amazon.com>,
"Evgeny Schemeilin" <evgenys@amazon.com>,
"Ron Beider" <rbeider@amazon.com>,
"Amit Bernstein" <amitbern@amazon.com>,
"Wajeeh Atrash" <atrwajee@amazon.com>,
"Gaetan Rivet" <grive@u256.net>,
"Xingui Yang" <yangxingui@huawei.com>,
"Chengwen Feng" <fengchengwen@huawei.com>,
"Bruce Richardson" <bruce.richardson@intel.com>,
"Praveen Shetty" <praveen.shetty@intel.com>,
"Vladimir Medvedkin" <vladimir.medvedkin@intel.com>,
"Anatoly Burakov" <anatoly.burakov@intel.com>,
"Jingjing Wu" <jingjing.wu@intel.com>,
"Rosen Xu" <rosen.xu@altera.com>,
"Andrew Boyer" <andrew.boyer@amd.com>,
"Dariusz Sosnowski" <dsosnowski@nvidia.com>,
"Viacheslav Ovsiienko" <viacheslavo@nvidia.com>,
"Bing Zhao" <bingz@nvidia.com>, "Ori Kam" <orika@nvidia.com>,
"Suanming Mou" <suanmingm@nvidia.com>,
"Matan Azrad" <matan@nvidia.com>,
"Wenbo Cao" <caowenbo@mucse.com>,
"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>,
"Jerin Jacob" <jerinj@marvell.com>,
"Maciej Czekaj" <mczekaj@marvell.com>, <dev@dpdk.org>,
<techboard@dpdk.org>,
"Konstantin Ananyev" <konstantin.ananyev@huawei.com>,
"Ivan Malov" <ivan.malov@arknetworks.am>,
"Thomas Monjalon" <thomas@monjalon.net>
Subject: Re: Fixing MBUF_FAST_FREE TX offload requirements?
Date: Thu, 18 Sep 2025 08:13:27 -0700 [thread overview]
Message-ID: <20250918081327.06fcdadf@hermes.local> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F65442@smartserver.smartshare.dk>
On Thu, 18 Sep 2025 10:50:11 +0200
Morten Brørup <mb@smartsharesystems.com> wrote:
> Dear NIC driver maintainers (CC: DPDK Tech Board),
>
> The DPDK Tech Board has discussed that patch [1] (included in DPDK 25.07) extended the documented requirements to the RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE offload.
> These changes put additional limitations on applications' use of the MBUF_FAST_FREE TX offload, and made MBUF_FAST_FREE mutually exclusive with MULTI_SEGS (which is typically used for jumbo frame support).
> The Tech Board discussed that these changes do not reflect the intention of the MBUF_FAST_FREE TX offload, and wants to fix it.
> Mainly, MBUF_FAST_FREE and MULTI_SEGS should not be mutually exclusive.
>
> The original RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE requirements were:
> When set, application must guarantee that
> 1) per-queue all mbufs come from the same mempool, and
> 2) mbufs have refcnt = 1.
>
> The patch added the following requirements to the MBUF_FAST_FREE offload, reflecting rte_pktmbuf_prefree_seg() postconditions:
> 3) mbufs are direct,
> 4) mbufs have next = NULL and nb_segs = 1.
>
> Now, the key question is:
> Can we roll back to the original two requirements?
> Or do the drivers also depend on the third and/or fourth requirements?
IMHO fast free should be as much like normal as possible.
Only things that would have a measurable impact on performance would help.
The reason for the single mempool is mostly related to not requiring code
that would walk a multi-segment mbuf to disperse the segments to potentially
different pools.
The reason for the refcnt == 1 is that updating refcnt requires atomic
operations which need to read-modify-write on memory (not just cache).
And RMW operation can take several memory clock cycles.
prev parent reply other threads:[~2025-09-18 15:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 8:50 Morten Brørup
2025-09-18 9:09 ` Bruce Richardson
2025-09-18 10:00 ` Morten Brørup
2025-09-18 14:12 ` Konstantin Ananyev
2025-09-18 15:13 ` Stephen Hemminger [this message]
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=20250918081327.06fcdadf@hermes.local \
--to=stephen@networkplumber.org \
--cc=ajit.khaparde@broadcom.com \
--cc=amitbern@amazon.com \
--cc=anatoly.burakov@intel.com \
--cc=andrew.boyer@amd.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=atrwajee@amazon.com \
--cc=bingz@nvidia.com \
--cc=bruce.richardson@intel.com \
--cc=caowenbo@mucse.com \
--cc=dev@dpdk.org \
--cc=dsosnowski@nvidia.com \
--cc=evgenys@amazon.com \
--cc=fengchengwen@huawei.com \
--cc=grive@u256.net \
--cc=hemant.agrawal@nxp.com \
--cc=hkalra@marvell.com \
--cc=ivan.malov@arknetworks.am \
--cc=jerinj@marvell.com \
--cc=jingjing.wu@intel.com \
--cc=kirankumark@marvell.com \
--cc=konstantin.ananyev@huawei.com \
--cc=matan@nvidia.com \
--cc=mb@smartsharesystems.com \
--cc=mczekaj@marvell.com \
--cc=ndabilpuram@marvell.com \
--cc=orika@nvidia.com \
--cc=praveen.shetty@intel.com \
--cc=rbeider@amazon.com \
--cc=rosen.xu@altera.com \
--cc=sachin.saxena@oss.nxp.com \
--cc=shaibran@amazon.com \
--cc=skori@marvell.com \
--cc=skoteshwar@marvell.com \
--cc=somnath.kotur@broadcom.com \
--cc=suanmingm@nvidia.com \
--cc=techboard@dpdk.org \
--cc=thomas@monjalon.net \
--cc=viacheslavo@nvidia.com \
--cc=vladimir.medvedkin@intel.com \
--cc=yangxingui@huawei.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).