Hello Dariusz, On Tue, 23 Jun 2026 at 13:38, Dariusz Sosnowski <[email protected]> wrote: > > Main goal of this patchset is to address > https://bugs.dpdk.org/show_bug.cgi?id=1957
It is expected that experimental symbols may disappear overnight, and this bug could also be closed as NOTABUG. On the other hand, we do state in the doc that compatibility could be provided when stabilising an experimental API, so ok.. let's try. > but it also handles other recently stabilized symbols and has some minor > fixes: > > - Patch 1 - Fix RTE_VERSION_EXPERIMENTAL_SYMBOL macro on clang. Ouch... /me hides. > - Patch 2 - Allow function versioning inside drivers. > - Patch 3 - Version the function symbols stabilized in > > https://git.dpdk.org/dpdk/commit/?id=e8cab133645f5466ef75e511629add43b68a5027 > - Patch 4 - Introduce versioning macros for global variable symbols. > - Patch 5 - Version the function and variable symbols stabilized in > > https://git.dpdk.org/dpdk/commit/?id=4ee2f5c1cedf9ee7f39afa667f71b07f4004ba5c > > Issue is still not fully fixed for stabilized global variables: > rte_flow_dynf_metadata_offs and rte_flow_dynf_metadata_mask. Well, symbol versioning is not something for variables. Exposing global variables was a mistake from the start... Those were exported for "performance" reasons as those are accessed via inline helpers (but I am not sure there were benchmarks showing the benefits). I am for forbidding exports of global variables from now, unless some really good performance benchmark is provided (@techboard for info). Now, in practice for your issue, rather than reintroducing symbol aliases (technical solution that I dropped when refactoring the macros), I think we can do with some middle ground approach: - leaving the inline helpers as "stable" (not __rte_experimental), - restoring the EXPERIMENTAL version on the global variables, this will restore the location of those symbols from the previous ABI pov, and the checks won't catch this discrepancy anyway, - during 26.11, drop the EXPERIMENTAL version on those variables, In other words, stopping at your patch 3 of the series, then adding: $ git diff diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c index ec0fe08355..8bd21ccd31 100644 --- a/lib/ethdev/rte_flow.c +++ b/lib/ethdev/rte_flow.c @@ -23,11 +23,11 @@ #define FLOW_LOG RTE_ETHDEV_LOG_LINE /* Mbuf dynamic field name for metadata. */ -RTE_EXPORT_SYMBOL(rte_flow_dynf_metadata_offs) +RTE_EXPORT_EXPERIMENTAL_SYMBOL(rte_flow_dynf_metadata_offs, 19.11) int32_t rte_flow_dynf_metadata_offs = -1; /* Mbuf dynamic field flag bit number for metadata. */ -RTE_EXPORT_SYMBOL(rte_flow_dynf_metadata_mask) +RTE_EXPORT_EXPERIMENTAL_SYMBOL(rte_flow_dynf_metadata_mask, 19.11) uint64_t rte_flow_dynf_metadata_mask; /** > Patch 4 and 5 address the bug for these global variables, > by providing a single storage for both EXPERIMENTAL and > DPDK_26 variable symbol versions. > This is achieved through symbol aliasing. > But this solution is limited only to executables compiled with clang. > > clang and gcc have a different default behavior regarding relocations > of global variables exposed by shared libraries. > Yeah... not even thinking about adding MSVC in the list... -- David Marchand
