-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2.6Mpps with RecordTimeStamp() environment. Normal? #72
Comments
Without the replay it looks more or less normal. InfiniteSource needs probably some more HEADROOM to avoid packet copy in the encap elements. The packets are actually created from scratch and maybe even copied once in this setup. Replay will keep them in memory. Before REPLAY it is also a good thing to have EnsureDPDKBuffer to avoid a copy when sending the packet (using QUICK_CLONE 1 is even best). |
Thanks Tom! After reading https://github.com/kohler/click/wiki/FAQs-about-click I was hoping to catch something around 7Mpps but obviously, not every element is suitable. |
This case is very very different. I achieve at least 15MPPS with a single core of a middle range Xeon with a router config. But creating a packet, computing the chzcksumS after IP/UDP encap and copying the content to a DPDK buffer is very heavy. You may gain something by compiling with --enable-dpdk-pool for that last point. If you don't set headroom to InfiniteSource, I also think you have one more packet copy... |
This case is very very different. I achieve at least 15MPPS with a single core of a middle range Xeon with a router config. But creating a packet, computing the checksumS after IP/UDP encap and copying the content to a DPDK buffer is very heavy. You may gain something by compiling with --enable-dpdk-pool for that last point. If you don't set headroom to InfiniteSource, I also think you have one more packet copy... |
Following is the single pipeline packet generator
Yielding these results
Running on
No matter how many cores I pass, I get approximately 2.6Mpps as shown above. If I comment out the etherencap and udpencap, it is approx 3Mpps.
Is this expected?
The text was updated successfully, but these errors were encountered: