public inbox for dev@dpdk.org
 help / color / mirror / Atom feed
* [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