Hi, Thank you for your guidance, the rates are back to normal. After the new configuration.
BRs, Wisam Jaddo > -----Original Message----- > From: Morten Brørup <[email protected]> > Sent: Wednesday, July 8, 2026 7:25 PM > To: Wisam Jaddo <[email protected]>; NBU-Contact-Thomas Monjalon > (EXTERNAL) <[email protected]>; Andrew Rybchenko > <[email protected]> > Cc: [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 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. > > > > > > > > > >
