* Disable SPDK testing again?
@ 2025-10-31 8:38 David Marchand
2025-10-31 9:11 ` Morten Brørup
0 siblings, 1 reply; 6+ messages in thread
From: David Marchand @ 2025-10-31 8:38 UTC (permalink / raw)
To: Patrick Robb, Aaron Conole, dpdk-techboard; +Cc: ci, dev
Hello,
The SPDK target in UNH lab has been spewing warnings as SPDK build
itself compiles and links against a list of libraries and drivers,
regardless of the upstream dependencies.
https://github.com/spdk/dpdk/commit/74b1a804eda2ed99d1ecaae5b79de7df6d74e8ff and
https://github.com/spdk/spdk/blob/master/dpdkbuild/Makefile#L66
Until SPDK fixes this on their side (either adding argparse in their
static list, or using pkg-config for example and stopping patching
DPDK), linking SPDK binaries fails as the argparse lib now necessary
to EAL is not pulled:
/usr/bin/ld.bfd:
/usr/local/lib/x86_64-linux-gnu/librte_eal.a(eal_common_eal_common_options.c.o):
in function `eal_usage':
eal_common_options.c:(.text+0x16): undefined reference to
`rte_argparse_print_help'
/usr/bin/ld.bfd:
/usr/local/lib/x86_64-linux-gnu/librte_eal.a(eal_common_eal_common_options.c.o):
in function `eal_collate_args':
eal_common_options.c:(.text+0x953): undefined reference to `rte_argparse_parse'
/usr/bin/ld.bfd:
/usr/local/lib/x86_64-linux-gnu/librte_eal.a(eal_common_eal_common_options.c.o):
in function `eal_parse_args':
eal_common_options.c:(.text+0x343b): undefined reference to
`rte_argparse_parse_type'
collect2: error: ld returned 1 exit status
make[3]: *** [/root/workspace/Generic-DPDK-Compile-Meson/spdk/mk/spdk.app.mk:39:
spdk_lock] Error 1
make[2]: *** [/root/workspace/Generic-DPDK-Compile-Meson/spdk/mk/spdk.subdirs.mk:16:
lock] Error 2
make[1]: *** [/root/workspace/Generic-DPDK-Compile-Meson/spdk/mk/spdk.subdirs.mk:16:
thread] Error 2
While it is just a warning in the CI dashboard, I don't think we
should waste resources on this testing.
Opinions?
--
David Marchand
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Disable SPDK testing again?
2025-10-31 8:38 Disable SPDK testing again? David Marchand
@ 2025-10-31 9:11 ` Morten Brørup
2025-10-31 9:17 ` David Marchand
0 siblings, 1 reply; 6+ messages in thread
From: Morten Brørup @ 2025-10-31 9:11 UTC (permalink / raw)
To: David Marchand, Patrick Robb, Aaron Conole, dpdk-techboard,
bruce.richardson
Cc: ci, dev
> From: David Marchand [mailto:david.marchand@redhat.com]
> Sent: Friday, 31 October 2025 09.39
>
> Hello,
>
> The SPDK target in UNH lab has been spewing warnings as SPDK build
> itself compiles and links against a list of libraries and drivers,
> regardless of the upstream dependencies.
> https://github.com/spdk/dpdk/commit/74b1a804eda2ed99d1ecaae5b79de7df6d7
> 4e8ff and
> https://github.com/spdk/spdk/blob/master/dpdkbuild/Makefile#L66
>
>
> Until SPDK fixes this on their side (either adding argparse in their
> static list, or using pkg-config for example and stopping patching
> DPDK), linking SPDK binaries fails as the argparse lib now necessary
> to EAL is not pulled:
>
> /usr/bin/ld.bfd:
> /usr/local/lib/x86_64-linux-
> gnu/librte_eal.a(eal_common_eal_common_options.c.o):
> in function `eal_usage':
> eal_common_options.c:(.text+0x16): undefined reference to
> `rte_argparse_print_help'
> /usr/bin/ld.bfd:
> /usr/local/lib/x86_64-linux-
> gnu/librte_eal.a(eal_common_eal_common_options.c.o):
> in function `eal_collate_args':
> eal_common_options.c:(.text+0x953): undefined reference to
> `rte_argparse_parse'
> /usr/bin/ld.bfd:
> /usr/local/lib/x86_64-linux-
> gnu/librte_eal.a(eal_common_eal_common_options.c.o):
> in function `eal_parse_args':
> eal_common_options.c:(.text+0x343b): undefined reference to
> `rte_argparse_parse_type'
> collect2: error: ld returned 1 exit status
> make[3]: *** [/root/workspace/Generic-DPDK-Compile-
> Meson/spdk/mk/spdk.app.mk:39:
> spdk_lock] Error 1
> make[2]: *** [/root/workspace/Generic-DPDK-Compile-
> Meson/spdk/mk/spdk.subdirs.mk:16:
> lock] Error 2
> make[1]: *** [/root/workspace/Generic-DPDK-Compile-
> Meson/spdk/mk/spdk.subdirs.mk:16:
> thread] Error 2
>
>
> While it is just a warning in the CI dashboard, I don't think we
> should waste resources on this testing.
> Opinions?
We should ask ourselves why they are doing that.
Is something wrong (or incomplete) with our handling of -Denable_libs?
Are we including unnecessary optional libs?
It seems like they are using -Ddisable_libs, not -Denable_libs. Don't they know about -Denable_libs?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Disable SPDK testing again?
2025-10-31 9:11 ` Morten Brørup
@ 2025-10-31 9:17 ` David Marchand
2025-10-31 10:02 ` Morten Brørup
0 siblings, 1 reply; 6+ messages in thread
From: David Marchand @ 2025-10-31 9:17 UTC (permalink / raw)
To: Morten Brørup
Cc: Patrick Robb, Aaron Conole, dpdk-techboard, bruce.richardson, ci, dev
On Fri, 31 Oct 2025 at 10:11, Morten Brørup <mb@smartsharesystems.com> wrote:
> While it is just a warning in the CI dashboard, I don't think we
> > should waste resources on this testing.
> > Opinions?
>
> We should ask ourselves why they are doing that.
> Is something wrong (or incomplete) with our handling of -Denable_libs?
> Are we including unnecessary optional libs?
>
> It seems like they are using -Ddisable_libs, not -Denable_libs. Don't they know about -Denable_libs?
I reached out to some SPDK dev when I was working on enable_libs.
I also Cc: one of them on the patches but never got a reply.
--
David Marchand
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Disable SPDK testing again?
2025-10-31 9:17 ` David Marchand
@ 2025-10-31 10:02 ` Morten Brørup
2025-10-31 15:13 ` Patrick Robb
0 siblings, 1 reply; 6+ messages in thread
From: Morten Brørup @ 2025-10-31 10:02 UTC (permalink / raw)
To: David Marchand, bruce.richardson
Cc: Patrick Robb, Aaron Conole, dpdk-techboard, ci, dev
> From: David Marchand [mailto:david.marchand@redhat.com]
> Sent: Friday, 31 October 2025 10.18
>
> On Fri, 31 Oct 2025 at 10:11, Morten Brørup <mb@smartsharesystems.com>
> wrote:
> > While it is just a warning in the CI dashboard, I don't think we
> > > should waste resources on this testing.
> > > Opinions?
> >
> > We should ask ourselves why they are doing that.
> > Is something wrong (or incomplete) with our handling of -
> Denable_libs?
> > Are we including unnecessary optional libs?
> >
> > It seems like they are using -Ddisable_libs, not -Denable_libs. Don't
> they know about -Denable_libs?
>
> I reached out to some SPDK dev when I was working on enable_libs.
> I also Cc: one of them on the patches but never got a reply.
@Bruce, the SPDK patch [1] was signed off by Tomasz Zawadzki <tomasz.zawadzki@intel.com>; maybe you could try reaching out through internal Intel channels and educate him about -Denable_libs.
If we disable SPDK testing due to this SPDK bug, how will we notice when they fix it, so we can enable SPDK testing again?
[1]: https://github.com/spdk/dpdk/commit/74b1a804eda2ed99d1ecaae5b79de7df6d74e8ff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Disable SPDK testing again?
2025-10-31 10:02 ` Morten Brørup
@ 2025-10-31 15:13 ` Patrick Robb
2025-11-01 7:47 ` Morten Brørup
0 siblings, 1 reply; 6+ messages in thread
From: Patrick Robb @ 2025-10-31 15:13 UTC (permalink / raw)
To: Morten Brørup
Cc: David Marchand, bruce.richardson, Aaron Conole, dpdk-techboard, ci, dev
[-- Attachment #1: Type: text/plain, Size: 623 bytes --]
On Fri, Oct 31, 2025 at 6:02 AM Morten Brørup <mb@smartsharesystems.com>
wrote:
>
> If we disable SPDK testing due to this SPDK bug, how will we notice when
> they fix it, so we can enable SPDK testing again?
>
>
One option is I can disable SPDK testing for the "per-patch" testing, but
leave it enabled for the periodic (once per 48 hours) runs on DPDK main.
That way patch submitters aren't left wondering if their patch has broken
SPDK, but we will be able to check in later on the DPDK main periodic
builds to see if the SPDK side is fixed, at which point we can re-enable
SPDK for per-patch testing.
[-- Attachment #2: Type: text/html, Size: 983 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Disable SPDK testing again?
2025-10-31 15:13 ` Patrick Robb
@ 2025-11-01 7:47 ` Morten Brørup
0 siblings, 0 replies; 6+ messages in thread
From: Morten Brørup @ 2025-11-01 7:47 UTC (permalink / raw)
To: Patrick Robb
Cc: David Marchand, bruce.richardson, Aaron Conole, dpdk-techboard, ci, dev
> From: Patrick Robb [mailto:probb@iol.unh.edu]
> Sent: Friday, 31 October 2025 16.13
>
> On Fri, Oct 31, 2025 at 6:02 AM Morten Brørup <mb@smartsharesystems.com> wrote:
>
>> If we disable SPDK testing due to this SPDK bug, how will we notice when they fix it, so we can enable SPDK testing again?
>
>> One option is I can disable SPDK testing for the "per-patch" testing, but leave it enabled for the periodic (once per 48 hours) runs on DPDK main. That way patch submitters aren't left wondering if their patch has broken SPDK, but we will be able to check in later on the DPDK main periodic builds to see if the SPDK side is fixed, at which point we can re-enable SPDK for per-patch testing.
Yes, please do.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-11-01 7:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-10-31 8:38 Disable SPDK testing again? David Marchand
2025-10-31 9:11 ` Morten Brørup
2025-10-31 9:17 ` David Marchand
2025-10-31 10:02 ` Morten Brørup
2025-10-31 15:13 ` Patrick Robb
2025-11-01 7:47 ` Morten Brørup
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).