Interestingly the user space way is also used in the performance absolutist end of the spectrum, so userspace can talk to the HW without kernel involvement (Snabb, dpdk, etc).
indeed, but afaik these more or less depend on dedicating a cpu-thread to the software-thread because a cache eviction would completely wreck the performance
I think with networking appliances that are built from eg DPDK building blocks the main motivation for pinning and isolcpus usage is largely that users want to have a fixed topology of CPU cores, PCIe devices, NUMA memory pools/hugepages. But this doesn't really mean it would be necessary if we started using userspace networking drivers for general purpouse linux workloads.
For performance you want to reduce context switches between processes including the kernel. With kernel bypass you do everything in one process in the user space, but you are also losing out on features like sharing hardware resources between processes. With general user space drivers you will gain additional context switches. There are also ways to reduce the cost of those context switches though, like IO-uring that Linux recently got.
See eg https://talawah.io/blog/linux-kernel-vs-dpdk-http-performanc...
reply