From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 71ADE29CF for ; Tue, 19 Dec 2017 02:54:49 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2017 17:54:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,424,1508828400"; d="scan'208";a="12927693" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.241.224.254]) ([10.241.224.254]) by FMSMGA003.fm.intel.com with ESMTP; 18 Dec 2017 17:54:48 -0800 To: Adrien Mazarguil Cc: dev@dpdk.org, Stephen Hemminger References: <20171124172132.GW4062@6wind.com> <20171218162443.12971-1-adrien.mazarguil@6wind.com> <20171218162443.12971-3-adrien.mazarguil@6wind.com> From: Ferruh Yigit Message-ID: <29ee4328-363b-19e2-fcc5-c1af57395277@intel.com> Date: Mon, 18 Dec 2017 17:54:45 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171218162443.12971-3-adrien.mazarguil@6wind.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v1 2/3] net/hyperv: implement core functionality 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: Tue, 19 Dec 2017 01:54:50 -0000 On 12/18/2017 8:46 AM, Adrien Mazarguil wrote: > As described in more details in the attached documentation (see patch > contents), this virtual device driver manages NetVSC interfaces in virtual > machines hosted by Hyper-V/Azure platforms. > > This driver does not manage traffic nor Ethernet devices directly; it acts > as a thin configuration layer that automatically instantiates and controls > fail-safe PMD instances combining tap and PCI sub-devices, so that each > NetVSC interface is exposed as a single consolidated port to DPDK > applications. > > PCI sub-devices being hot-pluggable (e.g. during VM migration), > applications automatically benefit from increased throughput when present > and automatic fallback on NetVSC otherwise without interruption thanks to > fail-safe's hot-plug handling. > > Once initialized, the sole job of the hyperv driver is to regularly scan > for PCI devices to associate with NetVSC interfaces and feed their > addresses to corresponding fail-safe instances. > > Signed-off-by: Adrien Mazarguil <...> > + RTE_ETH_FOREACH_DEV(port_id) { <..> > + ret = rte_eal_hotplug_remove(bus->name, dev->name); <..> > + ret = rte_eal_hotplug_add("vdev", ctx->devname, ctx->devargs); Overall why this logic implemented as network PMD? Yes technically you can implement *anything* as PMD :), but should we? This code does eal level work (scans bus, add/remove devices), and for control path, and not a generic solution either (specific to netvsc and failsafe). Only device argument part of a PMD seems used, rest is unrelated to being a PMD. Scans netvsc changes in background and reflects them into failsafe PMD... Why this is implemented as PMD, not another entity, like bus driver perhaps? Or indeed why this in DPDK instead of being in application? <...>