DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Wisam Jaddo" <wisamm@nvidia.com>,
	"NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
	"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>
Cc: <dev@dpdk.org>, "Raslan Darawsheh" <rasland@nvidia.com>,
	"Maayan Kashani" <mkashani@nvidia.com>
Subject: RE: [PATCH v8] mempool: improve cache behaviour and performance
Date: Wed, 8 Jul 2026 18:24:41 +0200	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F65964@smartserver.smartshare.dk> (raw)
In-Reply-To: <LV2PR12MB5893086C50C6C4752CBA46BEA4FF2@LV2PR12MB5893.namprd12.prod.outlook.com>

> From: Wisam Jaddo [mailto:wisamm@nvidia.com]
> Sent: Wednesday, 8 July 2026 17.05
> 
> Hi,
> 
> Tested on ARM BF3:
> command:
> . /dpdk-testpmd -n 4  -a 0000:03:00.0,dv_flow_en=2  -a
> 0000:03:00.1,dv_flow_en=2  -a auxiliary:  -a 00:00.0 -c 0x30  -- --
> mbcache=512 -i  --nb-cores=1  --burst=64 --txd=256 --rxd=256  --record-
> burst-stats --record-core-cycles --auto-start

Thank you for the detailed response.

As noted in the release notes with the patch, the effective mempool cache size was changed to no longer be 1.5 times the configured cache size. (This change fixed bug 1027 [BZ1027].)
I.e. with your testpmd parameters the effective mbuf mempool cache size was reduced from 768 (1.5 * 512) to 512 mbufs.
In order to test with the same effective mbuf mempool cache size, you need to pass --mbcache=768.
And since 768 exceeds RTE_MEMPOOL_CACHE_MAX_SIZE (default 512) in rte_config.h, you also need to rebuild DPDK with that set to 1024 instead of 512.

[BZ1027] https://bugs.dpdk.org/show_bug.cgi?id=1027

Please let us know your updated test results, if you decide to retest with --mbcache=768 and DPDK rebuilt with RTE_MEMPOOL_CACHE_MAX_SIZE 1024.

> 
> No offloads, plain testpmd with auto-start.
> On the other end I have ixia generating the ipv4_udp traffic, with dest
> udp range from 65024 to 65280 "To send different packets with msg size
> 64Bytes.
> 
> We send 100% on TX side, and we read what we reactive back on RX side
> in ixia "using two ports agg."
> The results that we start to see after this commit is a degradation of
> 1.8% - 2%
> 
> BRs,
> Wisam Jaddo
> 
> > -----Original Message-----
> > From: Morten Brørup <mb@smartsharesystems.com>
> > Sent: Wednesday, July 8, 2026 5:09 PM
> > To: Wisam Jaddo <wisamm@nvidia.com>; NBU-Contact-Thomas Monjalon
> > (EXTERNAL) <thomas@monjalon.net>
> > Cc: dev@dpdk.org; Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>;
> > Raslan Darawsheh <rasland@nvidia.com>; Maayan Kashani
> > <mkashani@nvidia.com>
> > Subject: RE: [PATCH v8] mempool: improve cache behaviour and
> performance
> >
> > > From: Wisam Jaddo [mailto:wisamm@nvidia.com]
> > > Sent: Wednesday, 8 July 2026 14.28
> > >
> > > Hi,
> > >
> > > Our internal performance testing are showing degradation starting
> from
> > > this commit.
> > > The degradation is about 1.8% - 2% on small msg szies.
> >
> > What do you mean "small message sizes"?
> >
> > Also, please share more details about the test case:
> > Access pattern, e.g. pipelined across multiple threads or run-to-
> completion? If
> > possible, link to test case source code?
> > Get and put burst sizes?
> > Mempool cache size?
> > Mempool driver?
> >
> > PS: I assume it is about mbuf mempool. Or is it some other object
> type in the
> > mempool?
> >
> > >
> > > BRs,
> > > Wisam Jaddo
> > >
> > > > -----Original Message-----
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > Sent: Wednesday, June 10, 2026 2:07 PM
> > > > To: Morten Brørup <mb@smartsharesystems.com>
> > > > Cc: dev@dpdk.org; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>
> > > > Subject: Re: [PATCH v8] mempool: improve cache behaviour and
> > > performance
> > > >
> > > > 04/06/2026 13:48, Morten Brørup:
> > > > > This patch refactors the mempool cache to eliminate some
> > > > > unexpected behaviour and reduce the mempool cache miss rate.
> > > >
> > > > Applied, thanks.
> > > >
> > > >


  reply	other threads:[~2026-07-08 16:24 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-08 14:13 [PATCH] mempool: improve cache behaviour and performance Morten Brørup
2026-04-08 15:41 ` Stephen Hemminger
2026-04-09 10:25 ` [PATCH v2] " Morten Brørup
2026-04-09 11:05 ` [PATCH v3] " Morten Brørup
2026-04-15 13:40   ` Morten Brørup
2026-04-18 11:15 ` [PATCH v4] " Morten Brørup
2026-04-19  9:55 ` [PATCH v5] " Morten Brørup
2026-04-22 12:27   ` Morten Brørup
2026-04-27 15:21   ` Morten Brørup
2026-04-28  7:44   ` Andrew Rybchenko
2026-05-22 16:11   ` Bruce Richardson
2026-05-26  8:41     ` Morten Brørup
2026-05-26  9:39       ` Bruce Richardson
2026-05-26 10:37         ` Morten Brørup
2026-05-26 17:45           ` Morten Brørup
2026-05-27  8:48             ` Bruce Richardson
2026-05-27  9:22               ` Morten Brørup
2026-05-22 16:12   ` Bruce Richardson
2026-05-26  8:57     ` Morten Brørup
2026-05-26 14:00 ` [PATCH v6] " Morten Brørup
2026-05-26 16:00   ` Morten Brørup
2026-06-01 13:36     ` Thomas Monjalon
2026-06-01 13:51       ` Morten Brørup
2026-06-01 14:19         ` Thomas Monjalon
2026-06-01 14:27           ` Morten Brørup
2026-05-29  8:53   ` fengchengwen
2026-05-29 11:43     ` Morten Brørup
2026-05-27 11:36 ` [PATCH v6] net/idpf: update for new mempool cache algorithm Morten Brørup
2026-05-27 11:36   ` [PATCH v6] mempool/dpaa: " Morten Brørup
2026-05-27 11:36   ` [PATCH v6] mempool/dpaa2: " Morten Brørup
2026-06-01 16:40 ` [PATCH v7] mempool: improve cache behaviour and performance Morten Brørup
2026-06-03 15:44   ` Thomas Monjalon
2026-06-01 18:36 ` [PATCH v7] net/idpf: update for new mempool cache algorithm Morten Brørup
2026-06-01 18:36   ` [PATCH v7] mempool/dpaa: " Morten Brørup
2026-06-02  6:51     ` Morten Brørup
2026-06-01 18:36   ` [PATCH v7] mempool/dpaa2: " Morten Brørup
2026-06-02  6:53     ` Morten Brørup
2026-06-02  6:45   ` [PATCH v7] net/idpf: " Morten Brørup
2026-06-10 11:21   ` Morten Brørup
2026-06-10 11:31     ` Bruce Richardson
2026-06-10 12:17       ` Thomas Monjalon
2026-06-10 12:34         ` Bruce Richardson
2026-06-10 11:31   ` Morten Brørup
2026-06-04 11:48 ` [PATCH v8] mempool: improve cache behaviour and performance Morten Brørup
2026-06-04 13:57   ` Morten Brørup
2026-06-10 11:06   ` Thomas Monjalon
2026-07-08 12:28     ` Wisam Jaddo
2026-07-08 14:08       ` Morten Brørup
2026-07-08 15:05         ` Wisam Jaddo
2026-07-08 16:24           ` Morten Brørup [this message]
2026-07-09 13:52             ` Wisam Jaddo

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=98CBD80474FA8B44BF855DF32C47DC35F65964@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=mkashani@nvidia.com \
    --cc=rasland@nvidia.com \
    --cc=thomas@monjalon.net \
    --cc=wisamm@nvidia.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