Netmap cannot (and does not want to) achieve the same performance of DPDK, but it has other advantages more than simpler installation, learning curve and flexibility (think of netmap pipes, netmap monitor ports and the VALE switch). Netmap applications can save CPU (sleep) when no traffic is needed, while DPDK applications must resort to busy waiting and need dedicated cores. This may be very handy for some applications, as you can find a sweet spot between high packet rate and CPU consumption. Moreover, Netmap uses the user<-->kernel interface to implement a layer of protection between the user-space application and the NIC hardware (performing validation on the application operations, which obviously comes with some cost). AFAIK, DPDK does not pay this cost, but allows unprotected access to the NIC hardware (which could do wild memory access through DMA). In terms of performance, benchmarks clearly show that DPDK has lower per-packet overhead (because it does less things), although netmap is not really far from those numbers. Point here is that benchmarks are often like free running engines; they show performance with no useful work. When you write a real application, you want to perform some useful work, which usually includes touching the packets, copying, compute packet headers etc; this results in expensive cache misses and CPU cycles that adds up to the basic I/O cost. If the real-work cost is something like 100ns per-packet (or more), then a difference in I/O cost of 5-10 nanoseconds per-packet may not really matter that much.