From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=d1AChb2Ssfd8HOA+D4ybcZTTWguXG6wzlkV5JSdA7Bc=; b=ARifzJZ6O6exc6NIKoBpNz3gJxHyyTHNX5K/hOPsk/Hwc5K9S6E7BUGsoQihHbJ757 LgnVaPJBvf12ROYKO6dwMKpe/tIB+XCakD5WC2G7Z/Jb8h2r/75E1TPFXUyQ1CQaoK1j wL2Wf13ffDiiO0d1SpH0KVjt2f/t3Bt8LoIvVG1rCayS8ecoDLkanpr36OQGIXkF08Oz WRbG9qAnS4bgm8buaJCmaboNVANA8xSFAF3rNy4U3GUMK9wpVsWJBc9oueFFsy5AXZ5q 32MPjxyMyahV//xbMvKFmMKKxlfA0KAYTk3GklYYYzlRTcUU/zro+gGYmEBz6mgcqVlj Hsdg== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=d1AChb2Ssfd8HOA+D4ybcZTTWguXG6wzlkV5JSdA7Bc=; b=EWjDQT8dpkViOsitN2mPmF7mLCbfwySuMAjCcWZ/KDXZA3OQsOwx51wyfcYqJbBot5 4S47kRWCqZQXqZ9whIzR3Xje0/MCGzqD0hQJbYwO9RBXWN+t9XJY0ja2zxp7FuTbjQGa kgY0QRKjyBdhW6F8B9ohuRy2VD9k0/k220CkIwAYCxdCfvjrR+Eyd8Yz/sFD7AEvRZyM bHVGc60CZb92oskMoX55j+wo876nIYGr3mVQMmaEUJ4rc0PegiZnhvve4ePsfmOAlguw /kjj9dhF5bPV0uFuNNbFq8Kb256IylK+CKuKb2JJWx1DaRTQ3PRtHCTzePhG7uGAiski va2Q== X-Gm-Message-State: AKGB3mJHf8Xt+WAptXWery4ed1InVsdHwaUyss38+I2QUfTZZ9wROQZX AYM618krEf3zZkC5Uws3Cq1JIQ== X-Google-Smtp-Source: ACJfBotKGutLZS9QHUy5JjUnSKa7J06N3SbIFhmY6r0ZAnyDmO6jiPcUGrVPrpTS5tXOv9w3/uAA3Q== X-Received: by 10.84.217.131 with SMTP id p3mr595056pli.270.1513621386518; Mon, 18 Dec 2017 10:23:06 -0800 (PST) Received: from xeon-e3 (204-195-18-133.wavecable.com. [204.195.18.133]) by smtp.gmail.com with ESMTPSA id z86sm28471968pff.4.2017.12.18.10.23.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 18 Dec 2017 10:23:06 -0800 (PST) Date: Mon, 18 Dec 2017 10:23:04 -0800 From: Stephen Hemminger To: Adrien Mazarguil Cc: Ferruh Yigit , dev@dpdk.org Message-ID: <20171218102304.66b2e98d@xeon-e3> In-Reply-To: <20171218162443.12971-1-adrien.mazarguil@6wind.com> 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 Subject: Re: [dpdk-dev] [PATCH v1 0/3] 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: Mon, 18 Dec 2017 18:23:07 -0000 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?