Re: [dpdk-dev] TX performance regression caused by the mbuf cachline split

[Paul Emmerich <emmericp@net.in.tum.de>]

Hi Luke,

thanks for your suggestion, I actually looked at how your packet 
generator in SnabbSwitch works before and it's quite clever. But 
unfortunately that's not what I'm looking for.

I'm looking for a generic solution that works with whatever NIC is 
supported by DPDK and I don't want to write NIC-specific transmit logic.
I don't want to maintain, test, or debug drivers. That's why I chose 
DPDK in the first place.

The DPDK drivers (used to) hit a sweet spot for the performance. I can 
usually load about two 10 Gbit/s ports on a reasonably sized CPU core 
without worrying about writing my own device drivers*. This allows for 
packet generation at interesting packet rates on low-end servers (e.g. 
servers with Xeon E3 1230 v2 CPUs and dual-port NICs). Servers with more 
ports usually also have the necessary CPU power to handle it.


I also don't want to be limited to packet generation in the long run. 
For example, I have a student who is working on an IPSec offloading 
application and another student working on a proof-of-concept router.


Paul


*) yes, I still need some NIC-specific low-level code (timestamping) and 
a small patch in the DPDK drivers (flag to disable CRC offloading on a 
per-packet basis) for some features of my packet generator.