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
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.
+
+ - 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
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
