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.
[...]
>>> [], [])
>>> +
>>> + DOCA_LINK=
>>> + case "$with_doca" in
>>> + "shared")
>>> + DOCA_LINK=shared
>>> + ;;
>>> + "static" | "yes")
>>> + DOCA_LINK=static
>>> + ;;
>>> + esac
>>> +
>>> + if test -n "$DOCA_LINK"; then
>>> + if test "$DOCA_LINK" != "$DPDK_LINK"; then
>>> + AC_MSG_ERROR(m4_normalize([DOCA requires --with-doca and --with-dpdk
>>> to be the same.]))
>>> + fi
>>> + fi
>> As mentioned in the introduction, we should not have a separate
>> option for --with-doca; it should silently follow the --with-dpdk
>> setting. It only needs to error out if --with-dpdk is not set.
> See my response above.
>>
>>> + AC_MSG_CHECKING([whether doca is enabled])
>>> + if test -z "$DOCA_LINK"; then
>>> + AC_MSG_RESULT([no])
>>> + DOCALIB_FOUND=false
>>> + else
>>> + AC_MSG_RESULT([yes])
>>> +
>>> + DOCA_PKGCONFIG="$(find /opt/mellanox/doca -type f -name doca-flow.pc
>>> -exec dirname {} \; | head -1)"
>>> + export
>>> PKG_CONFIG_PATH="$PKG_CONFIG_PATH${DOCA_PKGCONFIG:+${PKG_CONFIG_PATH:+:}}$DOCA_PKGCONFIG"
>>> +
>>> + AC_MSG_CHECKING([for DOCA in PKG_CONFIG_PATH='${PKG_CONFIG_PATH}'])
>> The AC_MSG_CHECKING has no matching AC_MSG_RESULT, so its output
>> runs into the PKG_CHECK_MODULES status on the same line. Either
>> change it to AC_MSG_NOTICE so it prints a complete line, or remove
>> it entirely since PKG_CHECK_MODULES already prints its own
>> "checking for DOCA..." status.
> Ack
>>
>>> + DOCA_PKGS="doca-flow doca-dpdk-bridge doca-common"
>>> + if test "$DOCA_LINK" = static; then
>>> + PKG_CHECK_MODULES_STATIC([DOCA], [$DOCA_PKGS], [],
>>> + [AC_MSG_ERROR([unable to use $DOCA_PKGS .pc files for $DOCA_LINK
>>> build])])
>>> + else
>>> + PKG_CHECK_MODULES([DOCA], [$DOCA_PKGS], [],
>>> + [AC_MSG_ERROR([unable to use $DOCA_PKGS .pc files for $DOCA_LINK
>>> build])])
>>> + 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.
>>> + if test "$DOCA_LINK" = static; then
>>> + # pkg-config --static may emit the same library in duplicate
>>> + # --whole-archive blocks when multiple packages share a dependency
>>> + # (both doca-flow and doca-dpdk-bridge pull in doca-common).
>>> + # Linking the same .a under --whole-archive twice causes "multiple
>>> + # definition" errors. Remove the second occurrence using a sed
>>> + # backreference, and strip redundant shared-lib flags (-l<lib>)
>>> + # since the static .a is already linked via --whole-archive.
>>> + DOCA_DEDUP_LIBS="doca_common doca_dpdk_bridge"
>>> + for lib in $DOCA_DEDUP_LIBS; do
>>> + lib_count=$(echo "$DOCA_LIBS" | grep -o "l:lib${lib}\.a" | wc -l)
>>> + if test "$lib_count" -ge 2; then
>>> + DOCA_LIBS=$(echo "$DOCA_LIBS" | sed "s@-Wl,--whole-archive -L[[^
>>> ]]* -l:lib${lib}\.a -Wl,--no-whole-archive -Wl,--as-needed @@2g")
>>> + fi
>>> + if echo "$DOCA_LIBS" | grep -q "l:lib${lib}\.a"; then
>>> + DOCA_LIBS=$(echo "$DOCA_LIBS" | sed "s/-l${lib}//g")
>>> + fi
>>> + done
>>> +
>>> + fi
>>> +
>>> + # Strip DPDK from DOCA_LIBS; it is covered by
>>> DPDK_LIB/DPDK_vswitchd_LDFLAGS.
>>> + DOCA_LIBS=$(echo "$DOCA_LIBS" | sed 's/-l:librte_[[^ ]]*\.a//g;
>>> s/-lrte_[[^ ]]*//g; s@-L[[^ ]]*/dpdk[[^ ]]*/lib[[^ ]]*@@g' | sed 's/ */
>>> /g; s/-Wl,--whole-archive *-Wl,--no-whole-archive//g; s/^ *//; s/ *$//')
>>> +
>>> + # For shared builds, ensure doca_common is included (may only be
>>> + # in Requires.private and not in Libs field of .pc files).
>>> + if test "$DOCA_LINK" = shared; then
>>> + if ! echo "$DOCA_LIBS" | grep -q "\-ldoca_common"; then
>>> + DOCA_LIBS="$DOCA_LIBS -ldoca_common"
>>> + fi
>>> + fi
>>> +
>>> + USED_PATH=$($PKG_CONFIG --variable=prefix doca-flow)
>>> + AC_MSG_NOTICE([Using DOCA release: '$USED_PATH'])
>>> +
>>> + ovs_save_CFLAGS="$CFLAGS"
>>> + ovs_save_LDFLAGS="$LDFLAGS"
>>> + # Statically linked libraries might have been built with sanitizers
>>> enabled.
>>> + # In such case, use the generated sanitizer cflags.
>>> + CFLAGS="$CFLAGS $SANITIZER_CFLAGS $DOCA_INCLUDE"
>> Is SANITIZER_CFLAGS needed here? It is never set anywhere in the
>> OVS build system, so it always expands to an empty string.
>> Sanitizer flags should be passed via CFLAGS to ./configure, as is
>> done for the rest of OVS.
> Ack. We have it as an explicit option for configure in our downstream version.
>>
>>> +
>>> + AC_MSG_CHECKING([for doca_flow.h])
>>> + AC_COMPILE_IFELSE(
>>> + [AC_LANG_PROGRAM([#include <doca_flow.h>],
>>> + [struct doca_flow_port *port = NULL ;])],
>>> + [AC_MSG_RESULT([yes])],
>>> + [AC_MSG_RESULT([no])
>>> + AC_MSG_ERROR(m4_normalize([
>>> + 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.
>>> + 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 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.
In addition, the rte_flow_tunnel related APIs are still
experimental. I assume you do not need them for DOCA?
[...]
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
