Harnessing Hardware for High-Performance Traffic Management in FD.io/VPP#

Venkata Ravichandra Mynidi, Alok Mishra

• Why: VPP does all traffic management (shaping, scheduling, policing) in software today, and CPU cost grows with traffic classes — a real SLA risk at 100G/200G+. This is the project's answer for QoS at 400G/800G, directly relevant to physical DC/telco datapaths.
• What: A vendor-neutral, capability-based framework that offloads VPP's TM to hardware TM engines in NICs, SmartNICs, and DPUs. Software TM remains fully supported; upstream patches are planned (the slides also reference Marvell DPU/adapter solutions).
• How: Hardware advertises TM capabilities; VPP adapts. Flows are classified in software (coupled with VPP's classifier, driven via binary APIs) and steered to hardware queues where hierarchical scheduling, dual-rate shaping (committed/peak, per the abstract RFC 2698-compliant), strict priority + weighted fairness, and line-rate policing are enforced. TM nodes support runtime add/update/suspend/resume/delete.
• Where applicable: Any VPP deployment needing per-tenant SLAs at high bandwidth; the API is designed to be silicon-agnostic, but real support depends on NICs/DPUs exposing TM engines. Caveat: the slides are mostly architecture diagrams — no benchmark numbers were presented, so treat the performance claims as directionally right but unproven.