[PATCH v4 0/9] Limit usage of internal API in tests
Stephen Hemminger
stephen at networkplumber.org
Tue Sep 29 21:50:00 CEST 2026
On Tue, 22 Sep 2026 11:40:16 +0200
David Marchand <david.marchand at redhat.com> wrote:
> We had a few bug reports related to internal (and experimental) symbols
> issues during 26.07 development.
> See for example https://bugs.dpdk.org/show_bug.cgi?id=1957 or more
> recently https://bugs.dpdk.org/show_bug.cgi?id=1967.
>
> To catch such issues earlier in the CI, this series proposes to run
> the unit tests through meson with the ABI reference unit test binary
> against the current ABI libraries and drivers.
>
> For this to work, some unit tests must be skipped (since meson may
> invoke the ABI reference code with tests that were unknown at the time).
>
> A few unit tests were directly dereferencing internal structures and are
> reworked so they use public APIs.
>
> Additionally, unit tests were allowed to use any internal API which has
> hidden a few issues (like a public API backed by internal symbols in the
> hash library).
> So disable the global ALLLOW_INTERNAL_API and move it to code explicitly
> requiring internal API, with the hope it will push us to have better API.
I think this causing breakage with minsize build. It is not correct to use
__rte_internal on inline helper functions in header file. I checked and only
thash has that anti-pattern.
In file included from ../lib/hash/rte_thash_gfni.h:13,
from ../lib/hash/rte_thash.h:23,
from ../app/test/test_thash_perf.c:13:
In function ‘rte_thash_gfni’,
inlined from ‘run_rss_calc’ at ../app/test/test_thash_perf.c:58:13:
../lib/hash/rte_thash_x86_gfni.h:181:27: error: call to ‘__rte_thash_gfni’ declared with attribute error: Symbol is not public ABI
181 | __m512i xor_acc = __rte_thash_gfni(m, tuple, NULL, len);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function ‘rte_thash_gfni_bulk’,
inlined from ‘run_rss_calc_bulk’ at ../app/test/test_thash_perf.c:79:3,
inlined from ‘run_thash_test’ at ../app/test/test_thash_perf.c:122:13:
../lib/hash/rte_thash_x86_gfni.h:213:27: error: call to ‘__rte_thash_gfni’ declared with attribute error: Symbol is not public ABI
213 | xor_acc = __rte_thash_gfni(mtrx, tuple[i], tuple[i + 1], len);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
AI analysis:
Pre-existing: the actual bug
lib/hash/rte_thash_x86_gfni.h:32 and :67 put __rte_internal on two static inline
helpers, __rte_thash_xor_reduce and __rte_thash_gfni. The public, stable (per
b9dd86db2a) wrappers rte_thash_gfni() / rte_thash_gfni_bulk() call them. Those
markers date to 4fd8c4cb0d ("hash: add new Toeplitz hash implementation") —
they've always been wrong. Any external application including rte_thash.h without
ALLOW_INTERNAL_API was already broken; 1f1c91397c just made DPDK's own tree hit
the same wall.
This is the same class of bug da31ef54c8 ("hash: fix GFNI stubs export") fixed
for the out-of-line stubs — it missed the inline helpers.
Why only minsize
__rte_internal expands to __attribute__((error(...))), which only fires if the
call survives to codegen:
-O0 : 6 -O1 : 0 -O2 : 0 -O3 : 0 -Os : 2
At -O1/-O2/-O3 GCC inlines the helper and the call vanishes. At -Os it declines
to inline (function too large), at -O0 it never inlines. So the marker was never
actually enforcing anything at the default optimization levels — it only
detonates under specific inlining decisions. minsize and a debug build are the
two configs that expose it.
Recommended fix
Drop __rte_internal from those two static inline helpers, rather than restoring
ALLOW_INTERNAL_API to app/test. __rte_internal on a static inline in an installed
public header is wrong by construction: there's no exported symbol to protect,
and it makes the public wrappers unusable from outside DPDK.
Verified: with those two markers removed, test_thash.c and test_thash_perf.c both
compile clean at -O0 and -Os (6→0 and 2→0). I grepped the rest of lib/ and
drivers/ for __rte_internal immediately preceding static inline in public headers
— these two are the only instances, so a single small patch covers it. Fixes:
should point at 4fd8c4cb0d, not 1f1c91397c.
More information about the dev
mailing list