Also make sure all core you are using are physical core not the logical core. Secondly, check your core isolation options and apply them accordingly.
. Regards, Nishant Verma On Mon, Sep 23, 2024 at 6:04 PM Wisam Jaddo <wis...@nvidia.com> wrote: > Hello Amit, > > > -----Original Message----- > > From: amit sehas <cu...@yahoo.com> > > Sent: Monday, September 23, 2024 11:57 PM > > To: users@dpdk.org > > Subject: core performance > > > > We are seeing different dpdk threads (launched > via rte_eal_remote_launch()), > > demonstrate very different performance. > > > > > > > > After placing counters all over the code, we realize that some threads > are > > uniformly slow, in other words there is no application level issue that > is > > throttling one thread over the other. We come to the conculsion that > either > > the Cores on which they are running are not at the same frequency which > > seems doubtful or the threads are not getting a chance to execute on the > cores > > uniformly. > > > > > > > > It seems that isolcpus has been deprecated in recent versions of linux. > > > > > > > > What is the recommended approach to prevent the kernel from utilizing > some > > CPU threads, for anything other than the threads that are launched on > them. > > If you are wishing to run each thread on separate core, try to use > rte_eal_mp_remote_launch() > instead of rte_eal_remote_launch(), make sure that your CPU is isolated, > and you are passing correct > Cores that were isolated to your app using -c, -l. > > > > > > > > > > Is there some API in dpdk which also helps us determine which CPU core > the > > thread is pinned to? > > > > I did not find any code in dpdk which actually performed pinning of a > thread to > > a CPU core. > > > > > > > > In our case it is more or less certain that the different threads are > simply not > > getting the same CPU core time, as a result some are demonstrating higher > > throughput than the others ... > > > > > > > > how do we fix this? > > BRs, > Wisam Jaddo >
