> From: Wisam Jaddo [mailto:[email protected]] > 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 <[email protected]> > > Sent: Wednesday, July 8, 2026 5:09 PM > > To: Wisam Jaddo <[email protected]>; NBU-Contact-Thomas Monjalon > > (EXTERNAL) <[email protected]> > > Cc: [email protected]; Andrew Rybchenko <[email protected]>; > > Raslan Darawsheh <[email protected]>; Maayan Kashani > > <[email protected]> > > Subject: RE: [PATCH v8] mempool: improve cache behaviour and > performance > > > > > From: Wisam Jaddo [mailto:[email protected]] > > > 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 <[email protected]> > > > > Sent: Wednesday, June 10, 2026 2:07 PM > > > > To: Morten Brørup <[email protected]> > > > > Cc: [email protected]; Andrew Rybchenko > <[email protected]> > > > > 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. > > > > > > > >
