[dpdk-dev] [RFC] Introduce virtual PMD for Hyper-V/Azure platforms

[Adrien Mazarguil]

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