Virtual machines hosted by Hyper-V/Azure platforms are fitted with simplified virtual network devices named NetVSC that are used for fast communication between VM to VM, VM to hypervisor, and the outside.
They appear as standard system netdevices to user-land applications, the main difference being they are implemented on top of VMBUS [1] instead of emulated PCI devices. While this reads like a case for a standard DPDK PMD, there is more to it. To accelerate outside communication, NetVSC devices as they appear in a VM can be paired with physical SR-IOV virtual function (VF) devices owned by that same VM [2]. Both netdevices share the same MAC address in that case. When paired, egress and most of the ingress traffic flow through the VF device, while part of it (e.g. multicasts, hypervisor control data) still flows through NetVSC. Moreover VF devices are not retained and disappear during VM migration; from a VM standpoint, they can be hot-plugged anytime with NetVSC acting as a fallback. Running DPDK applications in such a context involves driving VF devices using their dedicated PMDs in a vendor-independent fashion (to benefit from maximum performance without writing dedicated code) while simultaneously listening to NetVSC and handling the related hot-plug events. This new virtual PMD (referred to as "hyper-v" from this point on) automatically coordinates the Hyper-V/Azure-specific management part described above by relying on vendor-specific, fail-safe and tap PMDs to expose a single consolidated Ethernet device usable directly by existing applications, as summarized by the following diagram: .-------------. | DPDK ethdev | `------+------' | .------+------. | hyper-v PMD | `------+------' | .------------+------------. | fail-safe PMD | `--+-------------------+--' | | | .........|......... | : | : .----+----. : .------+------. : | tap PMD | : | $vendor PMD | : `----+----' : `------+------' :--- hot-pluggable | : | : .------+-------. : .-----+-----. : | NetVSC-based | : | SR-IOV VF | : | netdevice | : | device | : `--------------' : `-----------' : :.................: Given this RFC targets DPDK 18.02, this approach has the least impact on applications while work is being performed to enhance public DPDK APIs to improve it (e.g. hot-plug notification, vdev bus scanning and so on). Some highlights: - Enables existing applications to run unmodified with maximum performance on Hyper-V/Azure platforms. - All changes should be restricted to the hyper-v PMD (possibly a few in fail-safe PMD), no API change in DPDK. - Modular approach with little maintenance overhead (not much code) that will rely on existing PMDs for all the heavy lifting. [1] http://dpdk.org/ml/archives/dev/2017-January/054165.html [2] https://docs.microsoft.com/en-us/windows-hardware/drivers/network/overview-of-hyper-v -- Adrien Mazarguil 6WIND