* [RFC] net/vdev_netvsc: check for NetVSC device before auto-probe
@ 2026-02-22 20:48 Stephen Hemminger
2026-02-22 22:00 ` Stephen Hemminger
0 siblings, 1 reply; 4+ messages in thread
From: Stephen Hemminger @ 2026-02-22 20:48 UTC (permalink / raw)
To: dev; +Cc: Stephen Hemminger, stable, Matan Azrad
The custom scan callback unconditionally injects net_vdev_netvsc into
the devargs list on any Hyper-V system without checking whether NetVSC
interfaces actually exist. This causes the eal_flags_vdev_opt_autotest
to fail on GitHub Actions runners (which are Azure/Hyper-V VMs) because
the vdev bus probes both the test's intended vdev and the injected
net_vdev_netvsc, which fails to initialize on systems without NetVSC
interfaces.
Check whether at least one NetVSC interface exists (via the sysfs
class_id check the driver already uses) before adding devargs in the
scan callback.
Fixes: 56252de779a6 ("net/vdev_netvsc: add automatic probing")
Cc: stable@dpdk.org
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/net/vdev_netvsc/vdev_netvsc.c | 29 +++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c b/drivers/net/vdev_netvsc/vdev_netvsc.c
index f4a84783ce..0c7cd4aa4f 100644
--- a/drivers/net/vdev_netvsc/vdev_netvsc.c
+++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
@@ -768,6 +768,32 @@ RTE_PMD_REGISTER_PARAM_STRING(net_vdev_netvsc,
VDEV_NETVSC_ARG_FORCE "=<int> "
VDEV_NETVSC_ARG_IGNORE "=<int>");
+/**
+ * Check whether any NetVSC interface exists on the system.
+ *
+ * @return
+ * Nonzero value when at least one NetVSC interface is found, 0 otherwise.
+ */
+static int
+vdev_netvsc_any_netvsc_exists(void)
+{
+ struct if_nameindex *iface;
+ int ret = 0;
+ unsigned int i;
+
+ iface = if_nameindex();
+ if (iface == NULL)
+ return 0;
+ for (i = 0; iface[i].if_name != NULL; ++i) {
+ if (vdev_netvsc_iface_is_netvsc(&iface[i])) {
+ ret = 1;
+ break;
+ }
+ }
+ if_freenameindex(iface);
+ return ret;
+}
+
/** Compare function for vdev find device operation. */
static int
vdev_netvsc_cmp_rte_device(const struct rte_device *dev1,
@@ -798,6 +824,9 @@ vdev_netvsc_scan_callback(__rte_unused void *arg)
VDEV_NETVSC_DRIVER_NAME);
if (dev)
return;
+ /* Only inject if at least one NetVSC interface actually exists. */
+ if (!vdev_netvsc_any_netvsc_exists())
+ return;
if (rte_devargs_add(RTE_DEVTYPE_VIRTUAL, VDEV_NETVSC_DRIVER_NAME))
DRV_LOG(ERR, "unable to add netvsc devargs.");
}
--
2.51.0
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [RFC] net/vdev_netvsc: check for NetVSC device before auto-probe
2026-02-22 20:48 [RFC] net/vdev_netvsc: check for NetVSC device before auto-probe Stephen Hemminger
@ 2026-02-22 22:00 ` Stephen Hemminger
2026-02-23 21:42 ` [EXTERNAL] " Long Li
0 siblings, 1 reply; 4+ messages in thread
From: Stephen Hemminger @ 2026-02-22 22:00 UTC (permalink / raw)
To: dev; +Cc: stable, Matan Azrad, Long Li
On Sun, 22 Feb 2026 12:48:13 -0800
Stephen Hemminger <stephen@networkplumber.org> wrote:
> The custom scan callback unconditionally injects net_vdev_netvsc into
> the devargs list on any Hyper-V system without checking whether NetVSC
> interfaces actually exist. This causes the eal_flags_vdev_opt_autotest
> to fail on GitHub Actions runners (which are Azure/Hyper-V VMs) because
> the vdev bus probes both the test's intended vdev and the injected
> net_vdev_netvsc, which fails to initialize on systems without NetVSC
> interfaces.
>
> Check whether at least one NetVSC interface exists (via the sysfs
> class_id check the driver already uses) before adding devargs in the
> scan callback.
>
> Fixes: 56252de779a6 ("net/vdev_netvsc: add automatic probing")
> Cc: stable@dpdk.org
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
This is not sufficient to fix the github problem.
The container still has an interface, and cloud-init has given it
an address. But it has no route to outside (in container).
It looks like the whole automagic vdev_netvsc model is so brittle
it should be removed.
^ permalink raw reply [flat|nested] 4+ messages in thread* RE: [EXTERNAL] Re: [RFC] net/vdev_netvsc: check for NetVSC device before auto-probe
2026-02-22 22:00 ` Stephen Hemminger
@ 2026-02-23 21:42 ` Long Li
2026-02-23 23:01 ` Stephen Hemminger
0 siblings, 1 reply; 4+ messages in thread
From: Long Li @ 2026-02-23 21:42 UTC (permalink / raw)
To: Stephen Hemminger, dev@dpdk.org; +Cc: stable@dpdk.org, Matan Azrad
> Subject: [EXTERNAL] Re: [RFC] net/vdev_netvsc: check for NetVSC device before
> auto-probe
>
> On Sun, 22 Feb 2026 12:48:13 -0800
> Stephen Hemminger <stephen@networkplumber.org> wrote:
>
> > The custom scan callback unconditionally injects net_vdev_netvsc into
> > the devargs list on any Hyper-V system without checking whether NetVSC
> > interfaces actually exist. This causes the eal_flags_vdev_opt_autotest
> > to fail on GitHub Actions runners (which are Azure/Hyper-V VMs)
> > because the vdev bus probes both the test's intended vdev and the
> > injected net_vdev_netvsc, which fails to initialize on systems without
> > NetVSC interfaces.
> >
> > Check whether at least one NetVSC interface exists (via the sysfs
> > class_id check the driver already uses) before adding devargs in the
> > scan callback.
> >
> > Fixes: 56252de779a6 ("net/vdev_netvsc: add automatic probing")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > ---
>
> This is not sufficient to fix the github problem.
> The container still has an interface, and cloud-init has given it an address. But it
> has no route to outside (in container).
>
> It looks like the whole automagic vdev_netvsc model is so brittle it should be
> removed.
Can we set up a default config of not auto probing net_vdev_netvsc? Or some kind of flags that says a driver should not be auto loaded.
Most customers are running "vdev" arguments to load them in their DPDK application.
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [EXTERNAL] Re: [RFC] net/vdev_netvsc: check for NetVSC device before auto-probe
2026-02-23 21:42 ` [EXTERNAL] " Long Li
@ 2026-02-23 23:01 ` Stephen Hemminger
0 siblings, 0 replies; 4+ messages in thread
From: Stephen Hemminger @ 2026-02-23 23:01 UTC (permalink / raw)
To: Long Li; +Cc: dev@dpdk.org, stable@dpdk.org, Matan Azrad
On Mon, 23 Feb 2026 21:42:45 +0000
Long Li <longli@microsoft.com> wrote:
> >
> > This is not sufficient to fix the github problem.
> > The container still has an interface, and cloud-init has given it an address. But it
> > has no route to outside (in container).
> >
> > It looks like the whole automagic vdev_netvsc model is so brittle it should be
> > removed.
>
> Can we set up a default config of not auto probing net_vdev_netvsc? Or some kind of flags that says a driver should not be auto loaded.
>
> Most customers are running "vdev" arguments to load them in their DPDK application.
The problem is it runs in an initializer so it would have to be a build flag
rather than a runtime flag.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-02-23 23:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-22 20:48 [RFC] net/vdev_netvsc: check for NetVSC device before auto-probe Stephen Hemminger
2026-02-22 22:00 ` Stephen Hemminger
2026-02-23 21:42 ` [EXTERNAL] " Long Li
2026-02-23 23:01 ` Stephen Hemminger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox