From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id B93371B411 for ; Fri, 22 Dec 2017 19:01:41 +0100 (CET) Received: by mail-wm0-f51.google.com with SMTP id b199so23362914wme.1 for ; Fri, 22 Dec 2017 10:01:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=nkv2WxpxiwreJlyrsXDnxZdarPP1J73I0o9CYn0azX8=; b=qe9VH6IJ+XXnQ3DR42828ciD7kL1oPS56EI5eKiEAe5fpj3g4i3Q6t16momka4Tz7P Yb4eDwz4imTfUDfmnQNxUCWGEUQTxEPpPr7iptSfImFRT9z9RAw7HABx5yppBlVEscCV mZA4cK/cpL7A70zCkCshqQX87/7skIxKJAXZ1+IpjP7qFlpEG/kDTn/kWTRb81ApDt5V PUZQ46j+YYVooURA4WrD6HJ9VZ/pNyM/geJaRZkHr4GVlFHaZv/tDVFvYuHef1AVRgh5 x3L9bjafkNwyrzNCxTSphdA0YgJSzqEMi6LezU77ygiM28IT3KK2GIVHDe3kyxuUgCEj z2tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nkv2WxpxiwreJlyrsXDnxZdarPP1J73I0o9CYn0azX8=; b=cSD52gbTNdV6Ta/HEXrDjyijZt6bmSwtXm/Ho0VOQtsSv2o1tiAgKLFkKsRlMs6Z8P 3uedBGG5w2flqJySidb4fM9by4Sml7Ysppj6oeiHzkbjItjdSbo/g5SMAs/1IqYtnlr2 f+WbYZARkcpEexK9Lrz+7UKTRhMsujyxrO5FGLyuEAwn14+cV4K5nMqfh1B0YF/56GyR i/fFskQ1BeiVKnbwj75o0lNEEr6Kl/21S9HfCWWw58FDlDmTH8qN0vr+tMJrskTjxBkA 7vdkE85XdA0kmAF+A7MEz1aAn3jbeCRF07m5xlQlYal8xTGGeYv7XYW3Nx3FuIlP+sPh 7HeA== X-Gm-Message-State: AKGB3mIemBqi86EtsvMA6zYuxQiUcSIF58UzOOFWgzCnXljR5KLrh0/d ZYgPO8Ggy6mhdzKsedkbUTlR4Q== X-Google-Smtp-Source: ACJfBovVNJ5B5MS8c0LAOx5MRDaguQ9hg/J/dSgsIAnYG6NbIrOOo+X40pjrZ8EIoeOOriXDC3E8tw== X-Received: by 10.80.177.250 with SMTP id n55mr16571174edd.30.1513965701170; Fri, 22 Dec 2017 10:01:41 -0800 (PST) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id j39sm20079412ede.38.2017.12.22.10.01.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Dec 2017 10:01:39 -0800 (PST) Date: Fri, 22 Dec 2017 19:01:28 +0100 From: Adrien Mazarguil To: Ferruh Yigit Cc: dev@dpdk.org, Stephen Hemminger Message-ID: <20171222173846.20731-1-adrien.mazarguil@6wind.com> References: <20171218162443.12971-1-adrien.mazarguil@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171218162443.12971-1-adrien.mazarguil@6wind.com> X-Mailer: git-send-email 2.11.0 Subject: [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: Fri, 22 Dec 2017 18:01:41 -0000 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