From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 9697E271 for ; Tue, 19 Dec 2017 16:06:18 +0100 (CET) Received: by mail-wm0-f43.google.com with SMTP id g75so4370258wme.0 for ; Tue, 19 Dec 2017 07:06:18 -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=+LBaql3v7HAAG4hniZil0k836kpq2vidEVPL3eLAY6k=; b=UP2ntWP50E2PbdV4uB51//W6kvLRWapeD2oFSyNEf3WNL9gVwgjHeI86o8BTqKh4rC ERMWlMm1s8E9P/edM9Ho8t4A9k/c6T2kb9x4AnrzZMon1VSo7PdqSX8C0p6DAeHYOURX /FBru4ymNa4tgXoc8Cc0NUOBIQ3+MXyRbZcm0LlH8qCMFvMptHy7/wQEcaYWMZ8yimeL B00suJMBgMEjEqsZIAZdWlvkX8nSUg4dfAMlRjxVxDRZx/TMPXeXDbPTuDApbgUpBasT ypTrHGyOh5WZe4VtGCJRnHv/pT42KxRL8Ih6pBnLb73YCmNYFIYW+KJGWQi76HkMs8EC qaCQ== 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=+LBaql3v7HAAG4hniZil0k836kpq2vidEVPL3eLAY6k=; b=U6TKSMmqJ9u1V5iuJ588zFak6NXZnCiEKXYlEgG9FnM2Hd3yNuQm6hDwGHf9dqj3O6 qlVZQWDZpV6zBsZM6hnLnSjHxWXub4U3vIdaQbz8I14vDWJT34GHOzkshDAsKIxGWKHs SBnKX37giKesgoOIaOI0Z8C+q+RTWS/uUOB68cExRVsiAh8qVkGpSpyPzKtr2IMXnFqW 1mqw9A+qIqhxGhVQv1XAkfbbRH2bu5yhcKQnv4iosz1zrFIwNBO43oy/OCZQLNwW0yLJ mfJkQMUN3Ii9QZ8okSjxXPVqcuSKe02C8d0XgshvTFuBQCM5gkquVePc0+tBFwxZ0P8z 80YA== X-Gm-Message-State: AKGB3mICiazR1FFhJ/wOs/ALLNzv9VsFertzXjj9RdADEN8X/+ShYJWp IE8N8VFY8EPVvpZ0xAzdmLxXAQ== X-Google-Smtp-Source: ACJfBotuLTPqnR+LqUDyTll0pSVY5W+hnDYvmsg2PMud40DHUvqT8fZNdAknNGx8yb7gMp7YUbxXvQ== X-Received: by 10.80.134.108 with SMTP id 41mr979449edt.69.1513695978231; Tue, 19 Dec 2017 07:06:18 -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 e46sm14563405edb.93.2017.12.19.07.06.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Dec 2017 07:06:17 -0800 (PST) Date: Tue, 19 Dec 2017 16:06:05 +0100 From: Adrien Mazarguil To: Ferruh Yigit Cc: dev@dpdk.org, Stephen Hemminger Message-ID: <20171219150605.GG5377@6wind.com> References: <20171124172132.GW4062@6wind.com> <20171218162443.12971-1-adrien.mazarguil@6wind.com> <20171218162443.12971-3-adrien.mazarguil@6wind.com> <29ee4328-363b-19e2-fcc5-c1af57395277@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29ee4328-363b-19e2-fcc5-c1af57395277@intel.com> 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 15:06:18 -0000 On Mon, Dec 18, 2017 at 05:54:45PM -0800, Ferruh Yigit wrote: > 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? I'll address that last question first: the point of this driver is enabling existing applications to run within a Hyper-V environment unmodified, because they'd otherwise need to manage two driver instances correctly on their own in addition to hot-plug events during VM migration. Some kind of driver generating a front end to what otherwise appears as two distinct ethdev to applications is therefore necessary. Currently without it, users have to manually configure failsafe properly for each NetVSC interface on their system. Besides the inconvenience, it's not even a possibility with DPDK applications that don't rely on EAL command-line arguments. As such it's more correctly defined as a "platform" driver rather than a true PMD. It leaves VF device handling to their respective PMDs while automatically managing the platform-specific part itself. There's no simpler alternative when running in blacklist mode (i.e. not specifying any device parameters on the command line). Regarding its presence in drivers/net rather than drivers/bus, the end result from an application standpoint is that each instance exposes a single ethdev, even if not its own (failsafe's). Busses don't do that. It also allows passing arguments to individual devices through --vdev if needed. You're right about putting device detection at the bus level though, and I think there's work in progress to do just that, this driver will be updated to benefit from it once applied. In the meantime, the code as submitted works fine with the current DPDK code base and addresses an existing use case for which there is no solution at this point. -- Adrien Mazarguil 6WIND