core performance

[Stephen Hemminger]

On Tue, 24 Sep 2024 14:40:49 +0000 (UTC)
amit sehas <cun23 at 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 <cun23 at 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.