From: Bruce Richardson <bruce.richardson@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: <dev@dpdk.org>, Konstantin Ananyev <konstantin.ananyev@huawei.com>
Subject: Re: [PATCH 1/3] test/bpf: skip some testing if null net driver not present
Date: Thu, 22 Jan 2026 16:23:39 +0000 [thread overview]
Message-ID: <aXJPCy3H8j0pOA1H@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <20260122081948.5ce3a84b@phoenix.local>
On Thu, Jan 22, 2026 at 08:19:48AM -0800, Stephen Hemminger wrote:
> On Thu, 22 Jan 2026 12:23:51 +0000
> Bruce Richardson <bruce.richardson@intel.com> wrote:
>
> > Some of the BPF tests require the net/null driver to be present, so skip
> > those tests if it's not found. If the early part of the tests fail,
> > return that failure - on if they succeed do we return skipped on the
> > missing dependency.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
> > app/test/test_bpf.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/app/test/test_bpf.c b/app/test/test_bpf.c
> > index a7d56f8d86..ae588acb16 100644
> > --- a/app/test/test_bpf.c
> > +++ b/app/test/test_bpf.c
> > @@ -3725,6 +3725,11 @@ test_bpf_elf_rx_load(void)
> > return ret == 0 ? TEST_SUCCESS : TEST_FAILED;
> > }
> >
> > +#ifdef RTE_NET_NULL
> > +static const bool have_net_null = true;
> > +#else
> > +static const bool have_net_null; /* statics default to false */
> > +#endif
> >
> > static int
> > test_bpf_elf(void)
> > @@ -3732,6 +3737,10 @@ test_bpf_elf(void)
> > int ret;
> >
> > ret = test_bpf_elf_load();
> > + if (ret == TEST_SUCCESS && !have_net_null) {
> > + printf("net_null driver not available, skipping remainder of BPF tests\n");
> > + return TEST_SKIPPED;
> > + }
> > if (ret == TEST_SUCCESS)
> > ret = test_bpf_elf_tx_load();
> > if (ret == TEST_SUCCESS)
>
> Only the tests doing ELF load need a device.
> I think that part can be handled at compile time with the #ifdef
> or by splitting the ELF load tests to another file and doing it with meson.build
We could do that using ifdefs, but it means adding ifdefs around lots of
code blocks as the compiler will complain about unused functions if we just
ifdef out the calls to them. That's why I took this approach, to have the
minimal possible ifdef. If we don't want to mark the test as skipped we can
just change it to return success immedately if we don't have the null
driver.
/Bruce
next prev parent reply other threads:[~2026-01-22 16:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-22 12:23 [PATCH 0/3] manage net/null dependency for tests Bruce Richardson
2026-01-22 12:23 ` [PATCH 1/3] test/bpf: skip some testing if null net driver not present Bruce Richardson
2026-01-22 16:19 ` Stephen Hemminger
2026-01-22 16:23 ` Bruce Richardson [this message]
2026-01-22 22:17 ` [PATCH] test/bpf: skip the BPF ELF load tests if net null missing Stephen Hemminger
2026-01-23 7:55 ` Morten Brørup
2026-02-16 14:58 ` David Marchand
2026-01-22 12:23 ` [PATCH 2/3] test: fix missing dependency on null networking driver Bruce Richardson
2026-01-22 12:23 ` [PATCH 3/3] drivers: always enable the null net driver [RFC] Bruce Richardson
2026-01-22 13:13 ` Morten Brørup
2026-01-22 13:31 ` Bruce Richardson
2026-01-22 13:40 ` Morten Brørup
2026-01-22 14:59 ` Bruce Richardson
2026-01-22 16:09 ` Stephen Hemminger
2026-01-22 13:47 ` David Marchand
2026-01-22 14:57 ` Bruce Richardson
2026-01-22 15:37 ` Morten Brørup
2026-02-19 17:39 ` [PATCH v2 0/4] improve net/null dependency handling for tests Bruce Richardson
2026-02-19 17:39 ` [PATCH v2 1/4] test/event_eth_rx_adapter: skip tests if no ethdevs Bruce Richardson
2026-02-19 17:39 ` [PATCH v2 2/4] test/event_eth_tx_adapter: remove dependency on NULL PMD Bruce Richardson
2026-02-19 17:39 ` [PATCH v2 3/4] test: fix missing dependency on null networking driver Bruce Richardson
2026-02-19 17:39 ` [PATCH v2 4/4] build/tests: add warning for missing NULL PMD dependency Bruce Richardson
2026-02-19 19:44 ` [PATCH v2 0/4] improve net/null dependency handling for tests Morten Brørup
2026-03-03 16:29 ` David Marchand
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=aXJPCy3H8j0pOA1H@bricha3-mobl1.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@huawei.com \
--cc=stephen@networkplumber.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox