Suggestions to Enhance DPDK to Enable Migration of User Space Networking Applications to DPDK
summary
Proposes adding a reusable DPDK glue layer that gives user-space apps connection hooks, netlink state sync, zero-copy handoff at L2–L4 boundaries, and optional TLS crypto acceleration so existing apps reuse code instead of rewrites. Claims per-tunnel granular resource pools cut contention and doubled–tripled throughput in a migration, and that a 10 Gb NIC yields ~7–8 Gb with kernel TCP but falls to ~2 Gb with OpenVPN; target migrations raise 1 Gb workloads toward 3–4 Gb. Wants connection tables and flexible thread models.
AI-written summary · about
chapters (9)
- 0:00Introduction to DPDK enhancements
- 1:23Problem statement and context
- 8:30Customer requirements for migration
- 10:18Classifying user space applications
- 15:13Limitations of DPDK for user space apps
- 22:01Proposed framework for DPDK
- 30:15Thread usage models and resource pools
- 37:02Next steps and community involvement
- 52:03Q&A and discussion
related talks
23mDPDK in Databases: Why Isn’t It More Common?
20mCan OVS-DPDK be further optimised?
25mDPDK performance optimization for edge computing scenario
23mMigrating from DPDK to AF_XDP for High-Performance Networking in...
37mSPDK Based User Space NVMe Over TCP Transport Solution
24mCan a User-Space Protocol Stack Balance High Performance and Generality? Our Answer: Both.
51mAccelerate containers and VMs networking with vDPA
18mTGW: Operating an Efficient and Resilient Cloud Gateway at Scale