On 6/16/26 9:37 AM, Eelco Chaudron wrote: > > > 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?
The netdev-doca by itself doesn't have a lot of value for the OVS users without the offload provider, AFAIU, which we will not get within the current release cycle (there is simply not enough time to get everything reviewed). The main benefit of having it in git is to avoid dragging the patch set on the mailing list. Having it on dpdk-latest surely requires a bit more rebasing work than having it on main, but it still provides ability to have follow-up changes with a full CI coverage. And most rebases should be fairly straightforward. We could have it on main if there were no other obstacles, but without any benefit for OVS users there is really no reason to bring more experimental code into main. We should just stick with simple rules. Speaking of DOCA library itself, netdev-doca support in OVS should be clearly marked as experimental. Docuemtnation in this set doesn't do that. This is a new feature with a lot of code and custom config options that may change once we get more experience with it, we should be able to more easily change user interfaces on OVS level. Also, is there a documented policy for how DOCA library treats its own experimental APIs? I guess it's somewhat similar to DPDK and these APIs can change at any time without notice, right? Since whole DOCA support should be experimental the use of DOCA experimental APIs should not be a problem, but we'll need to target getting rid of them / stabilizing them before we can remove experimental label from DOCA support in OVS. Best regards, Ilya Maximets. > >>> 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
