From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by dpdk.org (Postfix) with ESMTP id A1AFB20F for ; Fri, 24 Nov 2017 18:21:45 +0100 (CET) Received: by mail-wm0-f54.google.com with SMTP id x63so23846835wmf.4 for ; Fri, 24 Nov 2017 09:21:45 -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=Tfj8SwuzeNlQ/Epre3zMtEVWzuNAVGnRtBOwnjUI00g=; b=qx4yX789zf3XQOcXSoTgkmnExWQ+xsWFkAfQXmbAUqI3CgPSjw3YWS9NspvsIKvjVF Y4hwfromfShdkCryYsfyaEFm+x/K8rXnKMzNU46vyGAjQJ+EwQHoTFw+M8MWQXZ0H9xX DBOk/50XI7DwKxkwC0xcDjocuaf+izPdsY5Q8AQIOvnX24Wl8F9Sf6RA/hNw4+xhC8x3 dD0qhN8obnwQkfjmrINkDVunsAWTAWLWe4lUs7fyWIV+hOXj8MbksdDHKQcuc7gW0j99 WjSN5NjL7AaUOG2cOzbrFKhupOAtXQe/1xflnXpCPGNm7ix+XYmAGLN9sczYaHZxhD+9 I6/A== 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=Tfj8SwuzeNlQ/Epre3zMtEVWzuNAVGnRtBOwnjUI00g=; b=t2241ePHEdHcymIeruz3gy3B1wcXM2eFTaIya4rgWsdzb/D+Qi7nDDz+emAeZxyFwt ZOi4Aq08p78YvGTMF57V+A3DpUZB5kgn4NKmoZYXTmCev8CTXTIFutxRtC7dxQWjZD2m r2r97rAsja6sdaTNCOjVUdubiSb9JchzMLGriwyr3icYTu2BOjebBNAk7to6ND7V+AkX LuOlxcTL1gF8VI0N+Wlm2IKhdxSm5xgoBUtPkVjxjmfAXYOkfyrUT1a6GgZ60tHd59+L c2KoeMTdQ/rXtVZ4+nOMZr7CR2EX50fL+qtsGLRsx1eqakAgC2VoEbzLkIG1sNPi6ihi CMHA== X-Gm-Message-State: AJaThX5xo2KS8XNze2NHNfT0lMU/o1/6Z8SsI0758AANxM6u3x0Jjldz 0SC9zgOSvN6QRjdf/EWOvwPBP5xW X-Google-Smtp-Source: AGs4zMaBX9+U71z4RnN8yTIcGgfh+8dkgd8UXH+nlLUC57IpwBNimdYw462vvft2FDpO1Lgzx3ozag== X-Received: by 10.80.208.150 with SMTP id v22mr38615815edd.62.1511544104871; Fri, 24 Nov 2017 09:21:44 -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 h4sm7901397edb.16.2017.11.24.09.21.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Nov 2017 09:21:43 -0800 (PST) Date: Fri, 24 Nov 2017 18:21:32 +0100 From: Adrien Mazarguil To: dev@dpdk.org Cc: Stephen Hemminger Message-ID: <20171124172132.GW4062@6wind.com> References: <20171124160801.GU4062@6wind.com> <20171124164812.GV4062@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171124164812.GV4062@6wind.com> Subject: [dpdk-dev] [RFC] 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, 24 Nov 2017 17:21:45 -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 "hyper-v" from this point on) automatically coordinates the Hyper-V/Azure-specific management part described above by relying on vendor-specific, fail-safe and tap PMDs to expose a single consolidated Ethernet device usable directly by existing applications, as summarized by the following diagram: .-------------. | DPDK ethdev | `------+------' | .------+------. | hyper-v PMD | `------+------' | .------------+------------. | fail-safe PMD | `--+-------------------+--' | | | .........|......... | : | : .----+----. : .------+------. : | tap PMD | : | $vendor PMD | : `----+----' : `------+------' :--- hot-pluggable | : | : .------+-------. : .-----+-----. : | NetVSC-based | : | SR-IOV VF | : | netdevice | : | device | : `--------------' : `-----------' : :.................: Given this RFC targets DPDK 18.02, this approach has the least impact on applications while work is being performed to enhance public DPDK APIs to improve it (e.g. hot-plug notification, vdev bus scanning and so on). Some highlights: - Enables existing applications to run unmodified with maximum performance on Hyper-V/Azure platforms. - All changes should be restricted to the hyper-v PMD (possibly a few in fail-safe PMD), no API change in DPDK. - Modular approach with little maintenance overhead (not much code) that will rely on existing PMDs for all the heavy lifting. [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 -- Adrien Mazarguil 6WIND