[dpdk-dev] [PATCH v1 2/3] net/hyperv: implement core functionality

Ferruh Yigit ferruh.yigit at intel.com
Tue Dec 19 02:54:45 CET 2017

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 <adrien.mazarguil at 6wind.com>


> +	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?


More information about the dev mailing list