On 15/06/2026 17:34, Eelco Chaudron wrote:
External email: Use caution opening links or attachments
On 15 Jun 2026, at 13:09, Eli Britstein wrote:
On 11/06/2026 12:07, Eelco Chaudron wrote:
External email: Use caution opening links or attachments
On 18 May 2026, at 13:27, Eli Britstein wrote:
From: Ariel Levkovich <[email protected]>
Add a new option to build ovs with doca by specifying '--with-doca' in the
configure line.
This flag must be used along with '--with-dpdk'. Otherwise the configure step
will fail.
An example:
./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc \
--with-dpdk=static --with-doca=static
Note that the value selected for doca must be the same as selected for
dpdk.
Hi Ariel/Eli,
Thanks for the new revision. I think we should not require a separate
option for --with-doca, it should figure out the link mode from
--with-dpdk and use that. So your last line in the commit message
can be removed as it makes no sense to explicitly configure the same.
I think there should be an explicit knob to compile with doca.
I'd prefer to keep it as is, e.g. --with-doca (and a validity check for linkage
type as dpdk).
The previous suggestion "--enable-doca" is explicit, but it's not consistent with other
"with" options, but if you are really against --with-doca we can go with that.
WDYT?
I meant to say, just add the --with-doca option, but not allowing
any parameters. It will take static/shared from whatever is
configured with --with-dpdk.
OK
[...]
[], [])
+
...
+ fi
+ DOCA_INCLUDE="$DOCA_CFLAGS -DDOCA_ALLOW_EXPERIMENTAL_API"
Is DOCA_ALLOW_EXPERIMENTAL_API needed? If so, which specific
DOCA APIs require it, and will they become non-experimental
before we release the first version?
We are checking what can be done about this.
Doca is getting mature over time and there are still API changes from time to
time.
OVS should compile/link only with a supported doca version and allowing those
API are specific to netdev-doca and doesn't have any affect on generic OVS.
If for now we do not need this flag, we should not set it. If we
need it in later additions we can add it as part of the specific
patch, and maybe remove it in later ones.
I meant for now we do need it as we use such API.
By "we are checking" I meant if we can promote them for the next
release. For offloads we will need few more and many more for CT.
+ if test "$DOCA_LINK" = static; then
+ # pkg-config --static may emit the same library in duplicate
...
+ Unable to include doca_flow.h, check the config.log for more details.
+ As a DOCA library was found in the current search path, a missing
doca_flow.h
+ usually means that it was built without DOCA-flow support.
+ Verify that you fulfilled all DOCA-flow build dependencies and that
it
+ was not automatically disabled.]))
+ ])
+
+ # DPDK was stripped from DOCA_LIBS above; add DPDK_LIB for the link test.
+ if test "$DOCA_LINK" = static; then
+ LIBS="$DOCA_LIBS $DPDK_LIB $ovs_save_libs_before_dpdk"
+ else
+ LIBS="$DOCA_LIBS $ovs_save_libs_before_dpdk"
+ fi
The ovs_save_libs_before_dpdk pattern can be avoided if LIBS is
restored after the DPDK link test, the same way CFLAGS and LDFLAGS
are already restored. The DPDK link test is the only consumer of
DPDK_LIB in LIBS; the actual binary uses DPDK_vswitchd_LDFLAGS.
Something like (not tested):
In OVS_CHECK_DPDK, after AC_LINK_IFELSE:
LIBS="$ovs_save_LIBS"
Then in OVS_CHECK_DOCA the link test becomes:
ovs_save_LIBS="$LIBS"
if test "$DOCA_LINK" = static; then
LIBS="$DOCA_LIBS $DPDK_LIB $LIBS"
else
LIBS="$DOCA_LIBS $LIBS"
fi
AC_LINK_IFELSE(...)
LIBS="$ovs_save_LIBS"
This removes ovs_save_libs_before_dpdk entirely and follows the
same save/restore pattern already used for CFLAGS and LDFLAGS.
AI-assisted:
This cannot work with the current build structure.
LIBS is not used only for configure-time link tests. It becomes @LIBS@ in the
generated Makefiles and is appended to every link line, and libtool uses it to
populate dependency_libs in libopenvswitch.la (and Libs.private in the .pc
file).
After the DPDK link test we restore CFLAGS/LDFLAGS but intentionally leave
DPDK_LIB in LIBS. DPDK_vswitchd_LDFLAGS is added only for ovs-vswitchd and
mainly preserves the --whole-archive ordering for PMD drivers.
Other binaries (ovsdb-server, ovs-ofctl, unit tests, etc.) link against
libopenvswitch.la and depend on DPDK being present via $(LIBS) /
dependency_libs.
With --with-dpdk, real DPDK code lives in libopenvswitch (not stubs), so
restoring LIBS to its pre-DPDK value would drop DPDK from dependency_libs and
leave undefined rte_* references in binaries other than ovs-vswitchd on static
builds.
I see there is a work going on to change this structure, see:
https://patchwork.ozlabs.org/project/openvswitch/list/?series=503763
I guess we will have to adapt once this is accepted (or when we move to
meson...).
We can leave this as an open item for now, and rework this once
the library restructuring is in.
OK
+ AC_MSG_CHECKING([for DOCA-flow link])
+ AC_LINK_IFELSE(
+ [AC_LANG_PROGRAM([#include <doca_flow_net.h>
+ #include <doca_flow.h>],
+ [struct doca_flow_cfg *cfg;
+ int rv;
+ doca_flow_cfg_create(&cfg);
+ rv = doca_flow_init(cfg);
+ doca_flow_cfg_destroy(cfg);
+ return rv;])],
+ [AC_MSG_RESULT([yes])
+ DOCALIB_FOUND=true],
+ [AC_MSG_RESULT([no])
+ AC_MSG_ERROR(m4_normalize([
+ Unable to link with DOCA-flow, check the config.log for more
details.
+ If a working DOCA-flow library was not found in the current search
path,
+ update PKG_CONFIG_PATH for pkg-config to find the .pc file in a
proper location.]))
+ ])
+ CFLAGS="$ovs_save_CFLAGS"
+ LDFLAGS="$ovs_save_LDFLAGS"
+ # Keep bare DOCA libs (no --whole-archive) in LIBS; OVS_LDFLAGS covers the
rest.
+ 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.
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
