On 15 Jun 2026, at 17:36, Eli Britstein wrote:
> 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.
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.
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?
>> 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
