2.6Mpps with RecordTimeStamp() environment. Normal? about fastclick HOT 4 CLOSED

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...

from fastclick.

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).

from fastclick.

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.
I still have to figure out the latency caused by replay from the previous issue. I will keep you posted.

from fastclick.

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...

from fastclick.