A virtualisation platform currently runs its software-defined networking layer, including the virtual switch that connects every guest to the fabric, on the host CPU. As guest density grows, the host spends an increasing fraction of its cycles forwarding packets between guests and the network. The team wants to relieve this without changing the network model the guests see. Which DPU capability most directly addresses the bottleneck?
- APartitioning the host GPU into smaller instances so each guest receives a guaranteed slice of accelerator compute for packet forwarding.
- BEnabling time-slicing on the network adapter so each guest's traffic is processed in a fixed scheduling quantum to even out CPU load.
- CHardware-accelerating the virtual switch on the DPU so packet forwarding between guests and the fabric executes on the DPU rather than consuming host CPU cycles. Correct
- DMigrating the guests to a separate physical host whose CPU has a higher core count to absorb the growing forwarding load.
Why A is wrong: Tempting because GPU partitioning is a real isolation technique, but packet forwarding is a networking task, not a GPU workload; carving up the GPU does nothing for virtual-switch overhead on the CPU.
Why B is wrong: Plausible because scheduling quanta manage contention, but time-slicing the adapter does not remove the forwarding work from the host CPU; the cycles are still spent, just reordered.
Why C is correct: Correct: the DPU can run the virtual-switch data path in hardware, so the per-packet forwarding work is offloaded from the host CPU while guests keep seeing the same software-defined network.
Why D is wrong: Tempting as a capacity fix, but adding host cores only relocates the same CPU-bound forwarding overhead; the DPU instead removes that overhead from the host entirely by offloading the data path.