On 5/4/26 4:04 PM, Eelco Chaudron wrote: > > > On 4 May 2026, at 15:48, Eli Britstein wrote: > >> On 01/05/2026 13:00, Eelco Chaudron wrote:
[...] >>>> + fi >>>> + 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" >>>> + OVS_CFLAGS="$OVS_CFLAGS $DOCA_INCLUDE -Wno-deprecated-declarations >>>> -DALLOW_EXPERIMENTAL_API" >>> Why do we add -Wno-deprecated-declarations? Should we not see these >>> warnings? >> Removed >>> >>> 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? > > Ilya, can you elaborate on plans to remove all experimental APIs > from OVS, as this might affect DOCA? The plan is to remove from OVS main branch everything that is under ifdef ALLOW_EXPERIMENTAL_API. I'll post a patch for this somewhere soon. We have the dpdk-latest branch where the code will remain. The only feature gated by this config currently in OVS is the packet info restoration API. The reason it is gated is the not insignificant performance impact this API has on every packet even if it is not offloaded. It's been five years since the feature was added and there was no progress on DPDK side to make it non-experimental and it should not become non-experimental while there is a significant performance impact from using it. There was an attempt to make it faster by providing a dynamic mbuf flag, but checking dynamic flags still causes a performance impact due to calls into DPDK. This is also a reason why the experimental API should not be silently enabled for the user when a library is linked. It must be an opt-in so users will know what they are signing up to. We have a general rule of not accepting code that relies on experimental API. We have dpdk-latest for this kind of things. The exemption was granted to the tunnel offload implementation because it was a large piece of code that is hard to maintain separately and there was a hope that it will become stable in a relatively short amount of time. That was 5 years ago, so clearly that didn't work out. We don't have test coverage for this code on main, we don't even build it in CI on main (and we shouldn't), and as of today there is no hope for it to become performant enough to become stable within a reasonable timeline, as to my knowledge nobody is working on that. So, it's time to remove the code from main. It can live in the dpdk-latest branch where we have at least some compilation tests for the experimental API. And if someday it becomes stable, we can add it back to main. If DOCA requires DPDK's experimental API, then it should probably be targeted for dpdk-latest as well and then brought to main when it's no longer the case. Alternative might be to hide experimental calls inside the DOCA library, if it can't work without them. Then you could build DOCA with experimental API and let OVS build without. AFAIU, the symbols are still available in the binary DPDK libraries, so both DOCA and OVS should be able to link the same DPDK, even if one is built with experimental and the other is not. Though I didn't try. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
