From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f54.google.com (mail-pl0-f54.google.com [209.85.160.54]) by dpdk.org (Postfix) with ESMTP id EB1051B63A for ; Sat, 23 Dec 2017 03:07:00 +0100 (CET) Received: by mail-pl0-f54.google.com with SMTP id g2so13848925pli.8 for ; Fri, 22 Dec 2017 18:07:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HQVPyIRqK25P5TYWPt1WkDGqx/QCWre8+1xS8Jpq5hg=; b=lBRIv9lDsfC+K2kh/kQfWyafZykcJs1cGI+FsNi07x5e7lRObE8QTaKC49bV1/w2ze xEBfCVNR9pRVfQ/hO8tK14nt+WVRbt/A/50IPonnbft60dzArJ53/vkN3WVKj0Ij1NKS sEgACsFbfA5OTDGhLly1f3WStcrxWZfs3E4sjKtB2xUacmITJa08KiIhWc9leabB4P0+ alPNx9wdPhg/4hi6Tl8I89WGvwDCzU6lp9kPpBHSlpSsH07Kbhb7s5kgX0QR8ImEfJPx muZBlE+pkqj0MUohRwJFZJ/oRzFrtOFSxdXm9XGOsO+Zg4rkfcqTfo4Tx1hK78WaJYhR w4kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HQVPyIRqK25P5TYWPt1WkDGqx/QCWre8+1xS8Jpq5hg=; b=sLmsyu4b2pxj/ymrIUvdOW5X9MdfvJLvARFiY/BXAcaU7+nLYmCHyeWBJ7PQZeUdmx vVKOnMDgeEr0dUypKI66y64S+y0obrqx1rxyZEFioetJD/j2w3s8cvZhX+W51UOYIGTX 4mvmkm7deppaoI37owo5iu1DwnUjFhxJKWp869G8S+GwvEcgFlENR0ziTUyoHSWKZjd2 v69/RbhaaJhWt17Vh1o6BjjKiYocnm4/SK5glqDeYuTkciT7sPzVpoHEzw015iPWzt6D rAHsRerUGZXtWMVi7o5V+rrezkr2FGG8MKJnH8FTZtqDYjWXG0+L3tQLyOtKI/hCiwV3 XW1g== X-Gm-Message-State: AKGB3mIVD/WjYgxaS/opfarY7T2k+4lOuT8FlgKEWtgV9KmXJFcYnqZd 5fgNmDY+lsaxjkEaENWS1CbX9R79jTTqVgl7uugO2jEW X-Google-Smtp-Source: ACJfBouLB8fm4rXr83MklFrb2EwUd+VSR3B256LaEwhkqbLlOZN173BH2XNY0rlANQjPAgiaIBpDfnpWzCn6TS5Y16o= X-Received: by 10.84.173.1 with SMTP id o1mr16403338plb.135.1513994819623; Fri, 22 Dec 2017 18:06:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.167.81 with HTTP; Fri, 22 Dec 2017 18:06:58 -0800 (PST) Received: by 10.100.167.81 with HTTP; Fri, 22 Dec 2017 18:06:58 -0800 (PST) In-Reply-To: <20171222173846.20731-1-adrien.mazarguil@6wind.com> References: <20171218162443.12971-1-adrien.mazarguil@6wind.com> <20171222173846.20731-1-adrien.mazarguil@6wind.com> From: Stephen Hemminger Date: Fri, 22 Dec 2017 18:06:58 -0800 Message-ID: To: Adrien Mazarguil Cc: Ferruh Yigit , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v2 0/5] Introduce virtual PMD for Hyper-V/Azure platforms X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Dec 2017 02:07:01 -0000 Why does this need to be a PMD? Maybe we need some platform infrastructure? My definition of PMD is it can send and receive On Dec 22, 2017 10:01, "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 "vdev_netvsc" 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 +---------+ vdev_netvsc 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 > vdev_netvsc 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_vdev_netvsc 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 > > v2 changes: > > - Renamed driver from "hyperv" to "vdev_netvsc". This change covers > documentation and symbols prefix. > - Driver is now tagged EXPERIMENTAL. > - Replaced ether_addr_from_str() with a basic sscanf() call. > - Removed debugging code (memset() poisoning). > - Fixed hyperv_iface_is_netvsc()'s buffer allocation according to comments. > - Removed hyperv_basename(). > - Discarded unused variables through __rte_unused. > - Added separate but necessary free() bugfix for failsafe PMD. > - Added file descriptor input support to failsafe PMD. > - Replaced temporary bash execution; failsafe now reads device definitions > directly through a pipe without an intermediate bash one-liner. > - Expanded DEBUG/INFO/WARN/ERROR() macros as PMD_DRV_LOG(). > - Added dynamic log type (pmd.vdev_netvsc). > - Modified initialization code to probe devices immediately during startup. > - Fixed several snprintf() return value checks ("ret >= sizeof(foo)" is > more > appropriate than "ret >= sizeof(foo) - 1"). > > Adrien Mazarguil (5): > net/failsafe: fix invalid free > net/failsafe: add "fd" parameter > net/vdev_netvsc: introduce Hyper-V platform driver > net/vdev_netvsc: implement core functionality > net/vdev_netvsc: add "force" parameter > > MAINTAINERS | 6 + > config/common_base | 5 + > config/common_linuxapp | 1 + > doc/guides/nics/fail_safe.rst | 9 + > doc/guides/nics/features/vdev_netvsc.ini | 12 + > doc/guides/nics/index.rst | 1 + > doc/guides/nics/vdev_netvsc.rst | 116 +++ > drivers/net/Makefile | 1 + > drivers/net/failsafe/failsafe_args.c | 88 ++- > drivers/net/failsafe/failsafe_private.h | 3 + > drivers/net/vdev_netvsc/Makefile | 58 ++ > .../vdev_netvsc/rte_pmd_vdev_netvsc_version.map | 4 + > drivers/net/vdev_netvsc/vdev_netvsc.c | 722 +++++++++++++++++++ > mk/rte.app.mk | 1 + > 14 files changed, 1025 insertions(+), 2 deletions(-) > create mode 100644 doc/guides/nics/features/vdev_netvsc.ini > create mode 100644 doc/guides/nics/vdev_netvsc.rst > create mode 100644 drivers/net/vdev_netvsc/Makefile > create mode 100644 drivers/net/vdev_netvsc/rte_ > pmd_vdev_netvsc_version.map > create mode 100644 drivers/net/vdev_netvsc/vdev_netvsc.c > > -- > 2.11.0 >