[ovs-dev] [PATCH v3] acinclude: Autodetect DPDK when configuring OVS

Panu Matilainen pmatilai at redhat.com
Wed Mar 30 12:06:12 UTC 2016


On 03/25/2016 05:31 PM, Bhanuprakash Bodireddy wrote:
> When using DPDK datapath, the OVS configure script requires the DPDK
> build directory passed on --with-dpdk. This can be avoided if DPDK
> library, headers are in standard compiler search paths.
>
> This patch fixes the problem by searching for DPDK libraries in standard
> locations and configures OVS sources for dpdk datapath.
>
> If the install location is manually specified in "--with-dpdk"
> autodiscovery shall be skipped
>
> Signed-off-by: Bhanuprakash Bodireddy <bhanuprakash.bodireddy at intel.com>
> ---
>   acinclude.m4 | 61 ++++++++++++++++++++++++++++++++++++------------------------
>   1 file changed, 37 insertions(+), 24 deletions(-)
>
> diff --git a/acinclude.m4 b/acinclude.m4
> index f345c31..edb9563 100644
> --- a/acinclude.m4
> +++ b/acinclude.m4
> @@ -163,22 +163,32 @@ AC_DEFUN([OVS_CHECK_DPDK], [
>                 [AC_HELP_STRING([--with-dpdk=/path/to/dpdk],
>                                 [Specify the DPDK build directory])])
>
> -  if test X"$with_dpdk" != X; then
> -    RTE_SDK=$with_dpdk
> +  AC_MSG_CHECKING([whether dpdk datapath is enabled])
> +  if test -z "$with_dpdk" || test "$with_dpdk" == no; then
> +    AC_MSG_RESULT([no])
> +    DPDKLIB_FOUND=false
> +  elif test -n "$with_dpdk"; then
> +    AC_MSG_RESULT([yes])
> +    case "$with_dpdk" in
> +      yes)
> +        DPDK_AUTO_DISCOVER="true"
> +        ;;
> +      *)
> +        DPDK_AUTO_DISCOVER="false"
> +        ;;
> +    esac
>
> -    DPDK_INCLUDE=$RTE_SDK/include
> -    DPDK_LIB_DIR=$RTE_SDK/lib
> +    if $DPDK_AUTO_DISCOVER; then
> +      DPDK_INCLUDE="/usr/local/include/dpdk -I/usr/include/dpdk"
> +      DPDK_LIB_DIR="/usr/local/lib -L/usr/lib64 -L/usr/lib"

This raises questions like why /usr/lib64 but not /usr/local/lib64? 
However, the bigger issue there is that lib and lib64 contents cannot be 
mixed because on a system where lib64 paths are valid, lib paths are 
32bit libraries. The linker already knows all that, so instead of trying 
to guess paths in vain, just try to link to -ldpdk. If that fails then 
its either outside standard library paths or does not exist on the system.

The include path does need to be determined since it needs to be added 
to -I, those two locations should be enough though..

> +    else
> +      DPDK_INCLUDE="$with_dpdk/include"
> +      # If 'with_dpdk' is passed install directory, point to headers
> +      # installed in $DESTDIR/$prefix/include/dpdk
> +      AC_CHECK_FILE([$DPDK_INCLUDE/rte_config.h],,[AC_CHECK_FILE([$DPDK_INCLUDE/dpdk/rte_config.h],[DPDK_INCLUDE=$DPDK_INCLUDE/dpdk],[])])
> +      DPDK_LIB_DIR="$with_dpdk/lib"
> +    fi
>       DPDK_LIB="-ldpdk"
> -    DPDK_EXTRA_LIB=""
> -    RTE_SDK_FULL=`readlink -f $RTE_SDK`
> -
> -    AC_COMPILE_IFELSE(
> -      [AC_LANG_PROGRAM([#include <$RTE_SDK_FULL/include/rte_config.h>
> -#if !RTE_LIBRTE_VHOST_USER
> -#error
> -#endif], [])],
> -                    [], [AC_DEFINE([VHOST_CUSE], [1], [DPDK vhost-cuse support enabled, vhost-user disabled.])
> -                         DPDK_EXTRA_LIB="-lfuse"])

This is silently removing vhost-cuse/vhost-user detection. I personally 
wouldn't mind support for vhost-cuse dropped but this is not the way to 
do it, it belongs to a separate patch along with appropriate explanation.


	- Panu -



More information about the dev mailing list