From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH v1 0/3] Introduce virtual PMD for Hyper-V/Azure platforms Date: Mon, 18 Dec 2017 10:23:04 -0800 Message-ID: <20171218102304.66b2e98d@xeon-e3> References: <20171124172132.GW4062@6wind.com> <20171218162443.12971-1-adrien.mazarguil@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Ferruh Yigit , dev@dpdk.org To: Adrien Mazarguil Return-path: Received: from mail-pl0-f65.google.com (mail-pl0-f65.google.com [209.85.160.65]) by dpdk.org (Postfix) with ESMTP id 75DCF200 for ; Mon, 18 Dec 2017 19:23:07 +0100 (CET) Received: by mail-pl0-f65.google.com with SMTP id b12so5298052plm.3 for ; Mon, 18 Dec 2017 10:23:07 -0800 (PST) In-Reply-To: <20171218162443.12971-1-adrien.mazarguil@6wind.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, 18 Dec 2017 17:46:19 +0100 Adrien Mazarguil 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?