On 17 May 2026, at 11:59, Eli Britstein wrote:
> On 04/05/2026 17:04, Eelco Chaudron wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On 4 May 2026, at 15:48, Eli Britstein wrote:
>>
>>> On 01/05/2026 13:00, Eelco Chaudron wrote:
>>>> External email: Use caution opening links or attachments
>>>>
>>>>
>>>> On 1 Apr 2026, at 11:13, 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
>>>>>
>>>> Hi Ariel/Eli,
>>>>
>>>> See comments below.
>>>>
>>>> //Eelco
>>>>
>>>>> Co-authored-by: Salem Sol <[email protected]>
>>>>> Signed-off-by: Salem Sol <[email protected]>
>>>>> Co-authored-by: Eli Britstein <[email protected]>
>>>>> Signed-off-by: Eli Britstein <[email protected]>
>>>>> Signed-off-by: Ariel Levkovich <[email protected]>
>>>>> ---
>>>>> .ci/doca-build.sh | 36 ++++++
> ...
>>>>> It should do make check here, as minimal tests should still pass.
>>>>> See linux-build.sh for details on how to run it.
>>> I added it, but it failed in some ODP tests, that pass locally for me. I
>>> think there is some issue with it. I will keep investigating this but we
>>> may have some unrelated noise that I don't want to hold the series for it.
>> Some times they fail, but with the RECHECK=yes is should pass.
>> If not we need to figure out why.
>
> I looked into it. It fails in parsing the text files in test-dpparse.py.
>
> I posted a fix commit as a separated one. If it's included, tests pass.
>
> https://mail.openvswitch.org/pipermail/ovs-dev/2026-May/432151.html
Thanks, I have a huge backlog of patches, I'll add it to the list...
>>
>>>>> diff --git a/.ci/doca-install.sh b/.ci/doca-install.sh
>>>>> new file mode 100755
>>>>> index 000000000..5931bf821
>>>>> --- /dev/null
>>>>> +++ b/.ci/doca-install.sh
>>>>> @@ -0,0 +1,20 @@
>>>>> +#!/bin/bash
> ...
>>>>> + - name: install DOCA
>>>>> + run: ./.ci/doca-install.sh
>>>> We need this to be build against the DPDK_VER version of DPDK using the
>>>> cached
>>>> build. And probably also need a step to quick test to verify the output of
>>>> 'ovs-vswitchd -V'.
>>> We cannot use the cached dpdk version. It is a very minimal dpdk, without
>>> mlx5 pmd. Doca installation also provides the compatible dpdk (25.11 + few
>>> critical bug fixes - for advanced features that you probably won't
>>> encounter).
>>>
>>> I added the "DOCA" prefix to the print of the doca version and check it
>>> exists in -V.
>> We should build with upstream DPDK, as it is not clear what is in
>> the included DPDK. We, as in Red Hat, would probably also build
>> using upstream DPDK. I do not see any problems extending the cached
>> image to include the mlx5 PMD.
>
> The wishful thinking is to provide the vanilla upstream DPDK in doca package.
> In practice, as package is provided to customers, there are few critical bug
> fixes in mlx5 pmd that are included in parallel to sending them upstream.
>
> There won't be any issue building against upstream dpdk if it has mlx5 PMD.
>
> Anyway, I'll extend the cached version to include mlx5 and update using the
> cached version. Note that for that we'll need more installations.
Thanks!
>>
>>>>> +
>>>>> + - name: build
>>>>> + run: ./.ci/doca-build.sh
>>>>> +
>>>>> + - name: upload logs on failure
>>>>> + if: failure() || cancelled()
>>>>> + uses: actions/upload-artifact@v4
>>>>> + with:
>>>>> + name: logs-doca-ubuntu-${{ matrix.compiler }}-${{
>>>>> matrix.doca_link }}
>>>>> + path: config.log
>>>>> diff --git a/Makefile.am b/Makefile.am
>>>>> index a805f21d1..ddc3e931e 100644
>>>>> --- a/Makefile.am
>>>>> +++ b/Makefile.am
>>>>> @@ -77,6 +77,8 @@ EXTRA_DIST = \
>>>>> MAINTAINERS.rst \
>>>>> README.rst \
>>>>> NOTICE \
>>>>> + .ci/doca-build.sh \
>>>>> + .ci/doca-install.sh \
>>>>> .ci/dpdk-build.sh \
>>>>> .ci/dpdk-prepare.sh \
>>>>> .ci/linux-build.sh \
>>>>> diff --git a/acinclude.m4 b/acinclude.m4
>>>>> index 060c416f8..e8d475f37 100644
>>>>> --- a/acinclude.m4
>>>>> +++ b/acinclude.m4
>>>>> @@ -374,6 +374,179 @@ AC_DEFUN([OVS_CHECK_LINUX_AF_XDP], [
>>>>> AM_CONDITIONAL([HAVE_AF_XDP], test "$AF_XDP_ENABLE" = true)
>>>>> ])
>>>>>
>>>>> +dnl OVS_CHECK_DOCA
>>>>> +dnl
>>>>> +dnl Configure DOCA source tree
>>>>> +AC_DEFUN([OVS_CHECK_DOCA], [
>>>>> + AC_ARG_WITH([doca],
>>>>> + [AS_HELP_STRING([--with-doca=static],
>>>> The code below seems to have something like;
>>>> --with-doca=static|shared|<path>
>>>> should this be removed, or this help be updated? If the latter we also
>>>> need
>>>> documentation updates in the next patch.
>>> I removed the <path> option.
>>>> To simplify things, would it be an idea to align DOCA with DPDK?
>>>> Meaning, we just add an --enable-doca option and it takes the link
>>>> mode from whatever is configured for DPDK? A quick glance on the
>>>> changes shows a lot cleaner implementation.
>>> I agree we don't really need "mixed" linkage types.
>>>
>>> However, I tried it. It doesn't look simpler I prefer to keep it as is.
>>>
>>> Also, in the future we may remove the dependency with dpdk.
>> I guess the cleanup came from the removed path part. However if we allow
>> for mixed options we might need to test against it :(
> I think a separated --with-doca is clearer. I'll add a validation that it's
> the same as dpdk.
>>
>>>>> + [Specify "static" depending on the
>>>>> + DOCA libraries to use. A custom DOCA
>>>>> install path
>>>>> + can be used otherwise for local builds.])],
> ...
>>>>> + LIBS="$DOCA_LIBS $LIBS"
>>>>> + else
>>>>> + LIBS="$DOCA_LIBS $ovs_save_libs_before_dpdk"
>>>> I do not like saving the libraries in a variable and then replacing it.
>>>> Could we fix this in a cleaner way? Maybe delay adding DPDK_LIB to LIBS
>>>> until
>>>> after the DOCA check? We are also resetting some other variables below.
>>>>
>>>> Maybe we should split this up into something like:
>>>>
>>>> OVS_CHECK_DPDK
>>>> OVS_CHECK_DOCA
>>>> OVS_CHECK_DPDK_POST_DOCA
>>>>
>>>> Not sure if this would be accepted, but it might make things a bit
>>>> cleaner.
>>> I think it will be even less clear. Hopefully if we move to meson based
>>> compilation and stop using pkg-config it will simplify things a lot.
>>>
>>> For now, this is the way it is.
>> I know, but we could make it better as they seem to depend on each other,
>> and using global variables does not make much sense to me. Ilya any idea, as
>> you might have more experience with AC?
>>
>>>>> + fi
>>>>> + AC_MSG_CHECKING([for DOCA-flow link])
> ...
>>>>> Also, enabling experimental DPDK APIs globally with
>>>>> -DALLOW_EXPERIMENTAL_API
>>>>> is not desirable. There are plans to remove experimental APIs completely.
>>>>> Which specific DPDK APIs require this flag? It might be better to get
>>>>> those
>>>>> promoted out of experimental state instead.
>>> We must have ALLOW_EXPERIMENTAL_API. For example
>>> rte_pmd_mlx5_enable_steering().
>>>
>>> If all APIs we use become non-experimental we will be able to remove it.
>>> For now we can't.
>> Is there a list of APIs you are planning to use, so you can drive
>> this upstream in DPDK?
>
> rte_flow_dynf_metadata_register, rte_flow_dynf_metadata_offs, later also
> rte_flow_dynf_metadata_get
>
> rte_pmd_mlx5_enable_steering/rte_pmd_mlx5_disable_steering
Added David and Kevin to get their input on how they could move to
non-experimental.
>>
>> Ilya, can you elaborate on plans to remove all experimental APIs
>> from OVS, as this might affect DOCA?
>
> We will drive them to be promoted in dpdk. Until then, we still need them.
>
> There are few more API in doca itself that will be promoted. When all are
> promoted, doca will also remove -DALLOW_EXPERIMENTAL_API from their PC files.
>
> Until then, we still need this.
>
>>
>>>>> +
> ...
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
