From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stephen@networkplumber.org>
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 <dev@dpdk.org>; Sat, 23 Dec 2017 03:07:00 +0100 (CET)
Received: by mail-pl0-f54.google.com with SMTP id g2so13848925pli.8
 for <dev@dpdk.org>; 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 <stephen@networkplumber.org>
Date: Fri, 22 Dec 2017 18:06:58 -0800
Message-ID: <CAOaVG17BfgrEhU3aDfC1T+WSSiUm5=DfM3-HaK-4FTK4KGyH3w@mail.gmail.com>
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>, 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 <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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" <adrien.mazarguil@6wind.com>
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
>