All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: <dev@dpdk.org>, <stable@dpdk.org>,
	Thomas Monjalon <thomas@monjalon.net>,
	Pablo de Lara <pablo.de.lara.guarch@intel.com>
Subject: Re: [RFC] test/eal_flags: suppress vdev_netvsc auto-probe
Date: Mon, 23 Feb 2026 09:10:05 -0800	[thread overview]
Message-ID: <20260223091005.6733c193@phoenix.local> (raw)
In-Reply-To: <aZyHm4EmcMGe4ylr@bricha3-mobl1.ger.corp.intel.com>

On Mon, 23 Feb 2026 17:00:11 +0000
Bruce Richardson <bruce.richardson@intel.com> wrote:

> On Sun, Feb 22, 2026 at 06:49:44PM -0800, Stephen Hemminger wrote:
> > On Sun, 22 Feb 2026 14:15:42 -0800
> > Stephen Hemminger <stephen@networkplumber.org> wrote:
> >   
> > > On Hyper-V systems (including Azure-hosted CI), the vdev_netvsc
> > > driver auto-injects itself during vdev bus scan. This interferes
> > > with the vdev flag test causing the nodeaction subprocess to fail.
> > > 
> > > Suppress by passing net_vdev_netvsc,ignore=1 in the valid vdev
> > > test cases. The scan callback sees it already in devargs and
> > > skips injection; the probe honours ignore and does nothing.
> > > 
> > > Fixes: 0d684a783088 ("app/test: fix and separate --vdev unit test")
> > > Cc: stable@dpdk.org
> > > 
> > > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>  
> > 
> > Self NAK
> > 
> > This is not the underlying cause of the test failures.
> > The issue is likely parallel test invocation overlapping on the file prefix
> > which is already addressed by another pending patch series.
> > 
> > That said, something should be done about vdev_netvsc driver and github
> > interactions.  
> 
> I don't think it's parallel invocations - we don't run our unit tests in
> parallel in github actions. I'd also note that the current issues started
> appearing when we patched in support to pass through the drivers path to
> the secondary process calls so that they could match the primary instance.
> Therefore, I still suspect something in the pci or other bus scanning to be
> a problem. Do we need to disable the netvsc as in your patch and also pass
> in --no-pci to the test cases?
> 
> /Bruce

I am thinking that vdev_netvsc driver hack needs to have a way
of detecting whether it is being run in a test. Maybe getenv("DPDK_TEST")
or some other github detection.

      reply	other threads:[~2026-02-23 17:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-22 22:15 [RFC] test/eal_flags: suppress vdev_netvsc auto-probe Stephen Hemminger
2026-02-23  2:49 ` Stephen Hemminger
2026-02-23 17:00   ` Bruce Richardson
2026-02-23 17:10     ` Stephen Hemminger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260223091005.6733c193@phoenix.local \
    --to=stephen@networkplumber.org \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.