On 16/06/2026 10:37, Eelco Chaudron wrote:
+ if test "$DOCA_LINK" = static; then
+ doca_libs_no_wa=$(echo "$DOCA_LIBS" | sed 's/ *-Wl,--whole-archive//g;
s/ *-Wl,--no-whole-archive//g')
+ LIBS="$doca_libs_no_wa $ovs_save_libs_before_dpdk"
+ fi
+ OVS_CFLAGS="$OVS_CFLAGS $DOCA_INCLUDE -DALLOW_EXPERIMENTAL_API"
I guess the ALLOW_EXPERIMENTAL_API is a problem here, as we are
headed towards the direction of not allowing experimental APIs in
OVS main.
If I understand correctly, Ilya's suggestion is to use the
dpdk-latest branch, which is synced with main, but it allows
experimental APIs.
This is assuming you will get all your required APIs to
non-experimental in DPDK before the next DPDK release. Is this
on track? Are your patches/requests accepted in DPDK main?
With this we should be aligned for the February release.
Thoughts?
As updated OOB, those API promotion was accepted in dpdk:
4ee2f5c1cedf ("ethdev: promote flow metadata API to stable")
e8cab133645f ("net/mlx5: promote some private API to stable")
As there is no functionality change in them due to this promotion, only the attributes, I
still want to post it for "main" branch and waive it until moving to updated
dpdk version.
WDYT?
I think we do not want the same situation as with other
experimental features and AVX512. So the general consensus is to
keep experimental tags out of main.
I can understand the objection to tnl-pop API that has to be called per packet
and slows down datapath. However, it is not because it is experimental API (the
same issue would be even if it was a stable API).
The other concern is dead code that has to be maintained for vain.
For doca usage, both concerns don't apply.
The purpose of our work is to make it usable, not dead.
It uses dpdk API that are being used are currently experimental, promoted in
next dpdk version.
It also uses doca API marked as DOCA_EXPERIMENTAL.
IMO having the experimental issue (both for dpdk/doca) a requirement before we
can accept netdev-doca is too strict.
The concern is not about speed or dead code. The policy for main
is straightforward: no DPDK experimental APIs. This avoids
surprises when experimental APIs change or are removed between
DPDK releases.
OVS takes only LTS versions (YY.11).
Between YY to YY+1 any dpdk API can change, not only experimental.
The only difference is that for stable API there is more formality about
deprecation notice etc.
Since the DPDK promotions are already accepted, and the next DPDK
release will include them as stable, there is no practical gap.
Development can continue on the dpdk-latest branch, which is synced
with main and allows experimental APIs. Once OVS moves to the new
DPDK version, the flag is no longer needed and the code merges
cleanly into main.
Ilya any comments? WDYT?
Currently, DOCA adds ALLOW_EXPERIMENTAL_API as part as its pkg-config
files, so we can remove it from OVS.
Once doca is adapted to use the updated dpdk version, it will also
remove it there.
Can we still go with main branch like this?
I guess for this it should not be a problem, as we would probably
not get dpif-offload-doca before the next release, so it lines up
with the next DPDK release and the OVS release next February.
We use the DPDK API (that was recently promoted) in netdev-doca series. We will
not need more of them for offload.
In addition, the rte_flow_tunnel related APIs are still
experimental. I assume you do not need them for DOCA?
No.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
