On Tue, 24 Sep 2024 14:40:49 +0000 (UTC) amit sehas <cu...@yahoo.com> wrote:
> Thanks for your response, and thanks for your input on the set_priority, > > The best guess we have at this point is that this is not a dpdk performance > issue. This is an issue with some threads running into more context switches > than the others and hence not getting the same slice of the CPU. We are > certain that this is not a dpdk performance issue, the code > is uniformly slow in one thread versus the other and the threads are doing a > very large amount of work including accessing databases. The threads in > question are not really doing packet processing as much as other work. > > So this is certainly not a dpdk performance issue. This is an issue of kernel > threads not being scheduled properly or in the worse case the cores running > on different frequency (which is quite unlikely no the AWS Xeons we are > running this on). > > If you are asking for the dpdk config files to check for dpdk related > performance issue then we are quite certain the issue is not with dpdk > performance ... > On Mon, Sep 23, 2024 at 10:06 PM amit sehas <cu...@yahoo.com> wrote: > > Thanks for your response, i am not sure i understand your question ... we > > have our product that utilizes dpdk ... the commands are just our server > > commands and parameters ... and the lscpu is the hyperthreaded 8 thread > > Xeon instance in AWS ... The rules of getting performance in DPDK: - use DPDK threads (pinned) for datapath - use isolated CPU's for those DPDK threads - do not do any system calls - avoid floating point You can use tracing tools like strace or BPF to see what the thread is doing.
