[dpdk-dev] [PATCH v1 0/3] Introduce virtual PMD for Hyper-V/Azure platforms

[Adrien Mazarguil]

On Mon, Dec 18, 2017 at 10:23:04AM -0800, Stephen Hemminger wrote:
> On Mon, 18 Dec 2017 17:46:19 +0100
> Adrien Mazarguil <adrien.mazarguil at 6wind.com> wrote:
> 
> > 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 "hyperv" from this point on)
> > automatically coordinates the Hyper-V/Azure-specific management part
> > described above by relying on vendor-specific, failsafe and tap PMDs to
> > expose a single consolidated Ethernet device usable directly by existing
> > applications.
> > 
> >          .------------------.
> >          | DPDK application |
> >          `--------+---------'
> >                   |
> >            .------+------.
> >            | DPDK ethdev |
> >            `------+------'       Control
> >                   |                 |
> >      .------------+------------.    v    .------------.
> >      |       failsafe PMD      +---------+ hyperv PMD |
> >      `--+-------------------+--'         `------------'
> >         |                   |
> >         |          .........|.........
> >         |          :        |        :
> >    .----+----.     :   .----+----.   :
> >    | tap PMD |     :   | any PMD |   :
> >    `----+----'     :   `----+----'   : <-- Hot-pluggable
> >         |          :        |        :
> >  .------+-------.  :  .-----+-----.  :
> >  | NetVSC-based |  :  | SR-IOV VF |  :
> >  |   netdevice  |  :  |   device  |  :
> >  `--------------'  :  `-----------'  :
> >                    :.................:
> > 
> > Note this diagram differs from that of the original RFC [3], with hyperv no
> > longer acting as a data plane layer.
> > 
> > This initial version of the driver only works in whitelist mode. Users have
> > to provide the --vdev net_hyperv EAL option at least once to trigger it.
> > 
> > Subsequent work will add support for blacklist mode based on automatic
> > detection of the host environment.
> > 
> > [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
> > [3] http://dpdk.org/ml/archives/dev/2017-November/082339.html
> > 
> > Adrien Mazarguil (3):
> >   net/hyperv: introduce MS Hyper-V platform driver
> >   net/hyperv: implement core functionality
> >   net/hyperv: add "force" parameter
> > 
> >  MAINTAINERS                                   |   6 +
> >  config/common_base                            |   6 +
> >  config/common_linuxapp                        |   1 +
> >  doc/guides/nics/features/hyperv.ini           |  12 +
> >  doc/guides/nics/hyperv.rst                    | 119 +++
> >  doc/guides/nics/index.rst                     |   1 +
> >  drivers/net/Makefile                          |   1 +
> >  drivers/net/hyperv/Makefile                   |  58 ++
> >  drivers/net/hyperv/hyperv.c                   | 799 +++++++++++++++++++++
> >  drivers/net/hyperv/rte_pmd_hyperv_version.map |   4 +
> >  mk/rte.app.mk                                 |   1 +
> >  11 files changed, 1008 insertions(+)
> >  create mode 100644 doc/guides/nics/features/hyperv.ini
> >  create mode 100644 doc/guides/nics/hyperv.rst
> >  create mode 100644 drivers/net/hyperv/Makefile
> >  create mode 100644 drivers/net/hyperv/hyperv.c
> >  create mode 100644 drivers/net/hyperv/rte_pmd_hyperv_version.map
> > 
> 
> Please don't call this drivers/net/hyperv/
> that name conflicts with the real netvsc PMD that I am working on.
> 
> Maybe vdev-netvsc?

No problem with that, if vdev-netvsc is good for you, I can update it in v2
if needed.

I'm just curious, I was under the impression both drivers would remain kind
of complementary pending various API updates, in which case wouldn't it make
sense to use "netvsc" as the better name for the NetVSC PMD? ("hyperv" being
more a use case than a true PMD)

Otherwise I also don't mind overwriting the current "hyperv" PMD code base
with yours as soon as it's ready, this will most likely make it redundant
anyway.

-- 
Adrien Mazarguil
6WIND