d/numam-spdk
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
834e3c5a0e
numam-spdk/dpdkbuild/Makefile

205 lines
7.8 KiB
Makefile
Raw Normal View History

build: add dpdk as a submodule This will allow a git clone to default to an SPDK-specific version of the DPDK repository. Users can still override to use a separate DPDK repository/installation with the --with-dpdk configure script options. While here, remove gzip option for the git-archive operations in autopackage.sh. We need to add a git-archive for the DPDK submodule if we are using it, and compressing at -9 adds a lot of unnecessary time. Since we are not archiving these packages, there is no need to compress them. Also explicitly disable coverage and ubsan for the autopackage build, since this build is only to test compilation and is not actually used for any test execution. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I3cf8a2ed984003a175cdece6542636ede8cb2479
2017-05-08 22:07:13 +00:00
#
# BSD LICENSE
#
# Copyright (c) Intel Corporation.
# All rights reserved.
mk: Enable build of mlx5_pci compress PMD This PMD is availabe for BlueField2 DPU. It requires libmlx5, so configure file is updated to check if this library exists Change-Id: Ic0cfbfdf24af393381667435009fb6afc49d9181 Signed-off-by: Alexey Marchuk <alexeymar@mellanox.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/8780 Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2021-06-15 13:25:07 +00:00
# Copyright (c) 2021 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
build: add dpdk as a submodule This will allow a git clone to default to an SPDK-specific version of the DPDK repository. Users can still override to use a separate DPDK repository/installation with the --with-dpdk configure script options. While here, remove gzip option for the git-archive operations in autopackage.sh. We need to add a git-archive for the DPDK submodule if we are using it, and compressing at -9 adds a lot of unnecessary time. Since we are not archiving these packages, there is no need to compress them. Also explicitly disable coverage and ubsan for the autopackage build, since this build is only to test compilation and is not actually used for any test execution. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I3cf8a2ed984003a175cdece6542636ede8cb2479
2017-05-08 22:07:13 +00:00
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
#
# * Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# * Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in
# the documentation and/or other materials provided with the
# distribution.
# * Neither the name of Intel Corporation nor the names of its
# contributors may be used to endorse or promote products derived
# from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
SPDK_ROOT_DIR := $(abspath $(CURDIR)/..)
include $(SPDK_ROOT_DIR)/mk/spdk.common.mk
Makefile: Add possibility to uninstall spdk. Add uninstall target to makefiles to be able to perform reverse of install target. Fixes #464 This patch adds 'uninstall' target to makefile. 'make uninstall' will remove spdk_tgt app, headers, libraries and shared libraries from system directories defined by $DESTDIR. Additionaly, if there will be any empty directories left after this operation, they will be removed as well. Signed-off-by: Piotr Pelplinski <piotr.pelplinski@intel.com> Change-Id: I7b07fb4b81081d3914ff09165991fbe3a26b9067 Signed-off-by: Pawel Kaminski <pawelx.kaminski@intel.com> Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/431471 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2019-01-02 09:28:02 +00:00
.PHONY: all clean install uninstall
build: add dpdk as a submodule This will allow a git clone to default to an SPDK-specific version of the DPDK repository. Users can still override to use a separate DPDK repository/installation with the --with-dpdk configure script options. While here, remove gzip option for the git-archive operations in autopackage.sh. We need to add a git-archive for the DPDK submodule if we are using it, and compressing at -9 adds a lot of unnecessary time. Since we are not archiving these packages, there is no need to compress them. Also explicitly disable coverage and ubsan for the autopackage build, since this build is only to test compilation and is not actually used for any test execution. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I3cf8a2ed984003a175cdece6542636ede8cb2479
2017-05-08 22:07:13 +00:00
dpdkbuild: build dpdk with meson+ninja Makefile support in DPDK was deprecated and will be removed soon, so switch to the officially supported way of building DPDK - with meson and ninja. Two new tools. Basically, our Makefiles will invoke meson+ninja for DPDK, no other SPDK components are affected. Apparently DPDK wanted to move away from an octopus-like config system and the ideology behind meson configuration is simple now: build everything by default. Some PMDs can be explicitly disabled with meson command line, but all libraries (both static and shared versions) and test apps are built unconditionally. How long does it take to build minimal DPDK with meson? Too much. On my machine half of the total build time is spent on libraries we don't need at all. (I have some hacks up my sleeve to disable building those libraries - see the subsequent patch.) As for the official way of building a minimal DPDK, there was a patch [1] on dpdk mailing list to introduce more specific configuration, but it was rejected: > We talked about this a few times in the past, and it was actually one > of the design goals to _avoid_ replicating the octopus-like config > system of the makefiles. That's because it makes the test matrix > insanely complicated, not to mention the harm to user friendliness, > among other things. > > If someone doesn't want to use a PMD, they can just avoid installing it > - it's simple enough. > > Sorry, but from me it's a very strong NACK. Let's not follow that direction, hack the DPDK build system instead. As for advantages of meson+ninja over Makefiles? I can't find any. It's another build system that does a lot for you with some functions, magic options, and a built-in dependency system. It seems nice if you know the syntax, but it's another component that you need to learn, debug, and possibly find bugs in (there's a lot of github issues open for meson). I would compare it to CMake. As for changes in this patch: rather that explicitly disabling PMDs we don't need, specify a list of PMDs we do need and disable everything else found in ./dpdk/drivers/*. This way we won't have to disable the new PMDs as they're added to DPDK. Meson configuration also sets RTE_EAL_PMD_PATH #define to a valid directory with built PMD shared libs. When it's set, DPDK dynamically loads all shared libraries inside. The drivers there depend on DPDK shared libs and fail to load in static SPDK builds, so we disable them altogether by unsetting RTE_EAL_PMD_PATH in the meson-generated config file - just like DPDK Makefiles did. EAL checks for RTE_EAL_PMD_PATH being empty and skips loading any external PMDs then. We do it for both static and shared libs. We specify all PMDs at build time for now, so there's just no need to load them dynamically. We have three more hacks in our submodule: * disable building dpdk apps by commenting-out a line in dpdk/meson.build * disable building unnecessary libs (build everything that spdk *may* need) * build isa-l compress pmd with `-L[...] -lisal`. DPDK expects to find libisal with pkg-config. We don't want to prepare a pkg-config file, so comment-out a failing check in another meson.build file and provide isa-l through CFLAGS and LDFLAGS. We also need to make some changes to our test/external_code. First of all, -ldpdk is no more. Meson build generates a pkg-config file with all libs, but we'll switch to it in a separate patch - for now just specify all -lrte_ libs one by one. -Wl,--no-as-needed has to be added to some test cases, otherwise rte_mempool_ring isn't loaded. We don't use any APIs from this library, it only has a static constructor that provides a few callbacks used by rte_mempool_create(). Also, since DPDK now builds both static and shared libraries, we need to add -Wl,-Bstatic to force using static libswhere required. It's only needed for DPDK libs, but we use it for SPDK libs as well since there's no harm. As for performance: $ ./configure --enable-debug --with-crypto --with-reduce $ time make -j40 -C dpdkbuild all with meson: real 0m8.287s user 1m7.983s sys 0m10.548s before, with the old DPDK makefiles: real 0m20.232s user 0m55.921s sys 0m16.491s The subsequent builds are much faster too: $ time make -j40 -C dpdkbuild all meson: real 0m0.876s user 0m0.663s sys 0m0.217s makefiles: real 0m10.150s user 0m11.740s sys 0m6.772s [1] http://inbox.dpdk.org/dev/1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org/ Change-Id: Ic65db563014100bafb12e61ee0530cc2ae64401d Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1440 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2020-03-23 16:55:08 +00:00
DPDK_OPTS = -Denable_docs=false
dpdkbuild: disable building DPDK tests DPDK tests were usualy disabled in the DPDK submodule, as part of skipping dpdk/app directory. Since DPDK 18.02 -Dtests=false option was added to skip building tests in dpdk/app/test. This reduces the overall time taken to build DPDK from submodule without introducing new changes to DPDK. Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Change-Id: I425976fa38e09c140e517cccd8aeedd64c67b06c Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/10504 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Aleksey Marchuk <alexeymar@mellanox.com> Reviewed-by: Paul Luse <paul.e.luse@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2021-12-01 12:38:42 +00:00
DPDK_OPTS += -Dtests=false
ipsec_mb: use EXTRA_CFLAGS to point DPDK to intel-ipsec-mb submodule This allows us to remove the requirement to install intel-ipsec-mb to system directories. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I579655a98b515cf148b7cd17823a9bb541ea6ad7 Reviewed-on: https://review.gerrithub.io/c/440785 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Seth Howell <seth.howell5141@gmail.com> Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com>
2019-01-13 20:28:21 +00:00
DPDK_CFLAGS =
dpdkbuild: build dpdk with meson+ninja Makefile support in DPDK was deprecated and will be removed soon, so switch to the officially supported way of building DPDK - with meson and ninja. Two new tools. Basically, our Makefiles will invoke meson+ninja for DPDK, no other SPDK components are affected. Apparently DPDK wanted to move away from an octopus-like config system and the ideology behind meson configuration is simple now: build everything by default. Some PMDs can be explicitly disabled with meson command line, but all libraries (both static and shared versions) and test apps are built unconditionally. How long does it take to build minimal DPDK with meson? Too much. On my machine half of the total build time is spent on libraries we don't need at all. (I have some hacks up my sleeve to disable building those libraries - see the subsequent patch.) As for the official way of building a minimal DPDK, there was a patch [1] on dpdk mailing list to introduce more specific configuration, but it was rejected: > We talked about this a few times in the past, and it was actually one > of the design goals to _avoid_ replicating the octopus-like config > system of the makefiles. That's because it makes the test matrix > insanely complicated, not to mention the harm to user friendliness, > among other things. > > If someone doesn't want to use a PMD, they can just avoid installing it > - it's simple enough. > > Sorry, but from me it's a very strong NACK. Let's not follow that direction, hack the DPDK build system instead. As for advantages of meson+ninja over Makefiles? I can't find any. It's another build system that does a lot for you with some functions, magic options, and a built-in dependency system. It seems nice if you know the syntax, but it's another component that you need to learn, debug, and possibly find bugs in (there's a lot of github issues open for meson). I would compare it to CMake. As for changes in this patch: rather that explicitly disabling PMDs we don't need, specify a list of PMDs we do need and disable everything else found in ./dpdk/drivers/*. This way we won't have to disable the new PMDs as they're added to DPDK. Meson configuration also sets RTE_EAL_PMD_PATH #define to a valid directory with built PMD shared libs. When it's set, DPDK dynamically loads all shared libraries inside. The drivers there depend on DPDK shared libs and fail to load in static SPDK builds, so we disable them altogether by unsetting RTE_EAL_PMD_PATH in the meson-generated config file - just like DPDK Makefiles did. EAL checks for RTE_EAL_PMD_PATH being empty and skips loading any external PMDs then. We do it for both static and shared libs. We specify all PMDs at build time for now, so there's just no need to load them dynamically. We have three more hacks in our submodule: * disable building dpdk apps by commenting-out a line in dpdk/meson.build * disable building unnecessary libs (build everything that spdk *may* need) * build isa-l compress pmd with `-L[...] -lisal`. DPDK expects to find libisal with pkg-config. We don't want to prepare a pkg-config file, so comment-out a failing check in another meson.build file and provide isa-l through CFLAGS and LDFLAGS. We also need to make some changes to our test/external_code. First of all, -ldpdk is no more. Meson build generates a pkg-config file with all libs, but we'll switch to it in a separate patch - for now just specify all -lrte_ libs one by one. -Wl,--no-as-needed has to be added to some test cases, otherwise rte_mempool_ring isn't loaded. We don't use any APIs from this library, it only has a static constructor that provides a few callbacks used by rte_mempool_create(). Also, since DPDK now builds both static and shared libraries, we need to add -Wl,-Bstatic to force using static libswhere required. It's only needed for DPDK libs, but we use it for SPDK libs as well since there's no harm. As for performance: $ ./configure --enable-debug --with-crypto --with-reduce $ time make -j40 -C dpdkbuild all with meson: real 0m8.287s user 1m7.983s sys 0m10.548s before, with the old DPDK makefiles: real 0m20.232s user 0m55.921s sys 0m16.491s The subsequent builds are much faster too: $ time make -j40 -C dpdkbuild all meson: real 0m0.876s user 0m0.663s sys 0m0.217s makefiles: real 0m10.150s user 0m11.740s sys 0m6.772s [1] http://inbox.dpdk.org/dev/1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org/ Change-Id: Ic65db563014100bafb12e61ee0530cc2ae64401d Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1440 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2020-03-23 16:55:08 +00:00
DPDK_KMODS = false
ifeq ($(OS),FreeBSD)
DPDK_KMODS = true
Enable DPDK shared object build with SPDK shared object build. When building SPDK with shared objects, we should also build the DPDK submodule shared libraries. This will make it much easier for peole to link their applications against a dpdk shared library if the DPDK shared libraries installed on their system don't have all the symbols that SPDK needs. Also, add a linker argument to DPDK to specify that it should look in the dpdk subdirectory when linking libraries. Note: this change will not work until the default config options in the DPDK submodule are updated. Change-Id: I9546df7b84952eb20fe1ac98e3b3bbd0fcbda3a7 Signed-off-by: Seth Howell <seth.howell@intel.com> Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/463028 Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Reviewed-by: Jan Kryl <jan.kryl@mayadata.io> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
2019-07-24 02:09:21 +00:00
endif
dpdkbuild: build dpdk with meson+ninja Makefile support in DPDK was deprecated and will be removed soon, so switch to the officially supported way of building DPDK - with meson and ninja. Two new tools. Basically, our Makefiles will invoke meson+ninja for DPDK, no other SPDK components are affected. Apparently DPDK wanted to move away from an octopus-like config system and the ideology behind meson configuration is simple now: build everything by default. Some PMDs can be explicitly disabled with meson command line, but all libraries (both static and shared versions) and test apps are built unconditionally. How long does it take to build minimal DPDK with meson? Too much. On my machine half of the total build time is spent on libraries we don't need at all. (I have some hacks up my sleeve to disable building those libraries - see the subsequent patch.) As for the official way of building a minimal DPDK, there was a patch [1] on dpdk mailing list to introduce more specific configuration, but it was rejected: > We talked about this a few times in the past, and it was actually one > of the design goals to _avoid_ replicating the octopus-like config > system of the makefiles. That's because it makes the test matrix > insanely complicated, not to mention the harm to user friendliness, > among other things. > > If someone doesn't want to use a PMD, they can just avoid installing it > - it's simple enough. > > Sorry, but from me it's a very strong NACK. Let's not follow that direction, hack the DPDK build system instead. As for advantages of meson+ninja over Makefiles? I can't find any. It's another build system that does a lot for you with some functions, magic options, and a built-in dependency system. It seems nice if you know the syntax, but it's another component that you need to learn, debug, and possibly find bugs in (there's a lot of github issues open for meson). I would compare it to CMake. As for changes in this patch: rather that explicitly disabling PMDs we don't need, specify a list of PMDs we do need and disable everything else found in ./dpdk/drivers/*. This way we won't have to disable the new PMDs as they're added to DPDK. Meson configuration also sets RTE_EAL_PMD_PATH #define to a valid directory with built PMD shared libs. When it's set, DPDK dynamically loads all shared libraries inside. The drivers there depend on DPDK shared libs and fail to load in static SPDK builds, so we disable them altogether by unsetting RTE_EAL_PMD_PATH in the meson-generated config file - just like DPDK Makefiles did. EAL checks for RTE_EAL_PMD_PATH being empty and skips loading any external PMDs then. We do it for both static and shared libs. We specify all PMDs at build time for now, so there's just no need to load them dynamically. We have three more hacks in our submodule: * disable building dpdk apps by commenting-out a line in dpdk/meson.build * disable building unnecessary libs (build everything that spdk *may* need) * build isa-l compress pmd with `-L[...] -lisal`. DPDK expects to find libisal with pkg-config. We don't want to prepare a pkg-config file, so comment-out a failing check in another meson.build file and provide isa-l through CFLAGS and LDFLAGS. We also need to make some changes to our test/external_code. First of all, -ldpdk is no more. Meson build generates a pkg-config file with all libs, but we'll switch to it in a separate patch - for now just specify all -lrte_ libs one by one. -Wl,--no-as-needed has to be added to some test cases, otherwise rte_mempool_ring isn't loaded. We don't use any APIs from this library, it only has a static constructor that provides a few callbacks used by rte_mempool_create(). Also, since DPDK now builds both static and shared libraries, we need to add -Wl,-Bstatic to force using static libswhere required. It's only needed for DPDK libs, but we use it for SPDK libs as well since there's no harm. As for performance: $ ./configure --enable-debug --with-crypto --with-reduce $ time make -j40 -C dpdkbuild all with meson: real 0m8.287s user 1m7.983s sys 0m10.548s before, with the old DPDK makefiles: real 0m20.232s user 0m55.921s sys 0m16.491s The subsequent builds are much faster too: $ time make -j40 -C dpdkbuild all meson: real 0m0.876s user 0m0.663s sys 0m0.217s makefiles: real 0m10.150s user 0m11.740s sys 0m6.772s [1] http://inbox.dpdk.org/dev/1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org/ Change-Id: Ic65db563014100bafb12e61ee0530cc2ae64401d Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1440 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2020-03-23 16:55:08 +00:00
DPDK_OPTS += -Denable_kmods=$(DPDK_KMODS)
dpdkbuild: set --buildtype for debug builds When ./configure --enable-debug is specified, meson is invoked using the default 'release' buildtype and '-O0 -g' is added to DPDK_CFLAGS. Instead, specify --buildtype=debug so that meson knows it is a debug build, will return the correct value from get_option('buildtype') and can choose the appropriate toolset options to enable symbolic debugging. Using --buildtype=debug generates unoptimised code which matches the current intent. Tested by building with and without --enable-debug and verifying that meson reports 'debug' for the debug build. Signed-off-by: Nick Connolly <nick.connolly@mayadata.io> Change-Id: Iabb79cd2051145e03fea8fd749cfb18b78e625a0 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/6497 Community-CI: Broadcom CI Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Aleksey Marchuk <alexeymar@mellanox.com>
2021-02-23 09:57:14 +00:00
ifeq ($(CONFIG_DEBUG),y)
DPDK_OPTS += --buildtype=debug
endif
dpdkbuild: build dpdk with meson+ninja Makefile support in DPDK was deprecated and will be removed soon, so switch to the officially supported way of building DPDK - with meson and ninja. Two new tools. Basically, our Makefiles will invoke meson+ninja for DPDK, no other SPDK components are affected. Apparently DPDK wanted to move away from an octopus-like config system and the ideology behind meson configuration is simple now: build everything by default. Some PMDs can be explicitly disabled with meson command line, but all libraries (both static and shared versions) and test apps are built unconditionally. How long does it take to build minimal DPDK with meson? Too much. On my machine half of the total build time is spent on libraries we don't need at all. (I have some hacks up my sleeve to disable building those libraries - see the subsequent patch.) As for the official way of building a minimal DPDK, there was a patch [1] on dpdk mailing list to introduce more specific configuration, but it was rejected: > We talked about this a few times in the past, and it was actually one > of the design goals to _avoid_ replicating the octopus-like config > system of the makefiles. That's because it makes the test matrix > insanely complicated, not to mention the harm to user friendliness, > among other things. > > If someone doesn't want to use a PMD, they can just avoid installing it > - it's simple enough. > > Sorry, but from me it's a very strong NACK. Let's not follow that direction, hack the DPDK build system instead. As for advantages of meson+ninja over Makefiles? I can't find any. It's another build system that does a lot for you with some functions, magic options, and a built-in dependency system. It seems nice if you know the syntax, but it's another component that you need to learn, debug, and possibly find bugs in (there's a lot of github issues open for meson). I would compare it to CMake. As for changes in this patch: rather that explicitly disabling PMDs we don't need, specify a list of PMDs we do need and disable everything else found in ./dpdk/drivers/*. This way we won't have to disable the new PMDs as they're added to DPDK. Meson configuration also sets RTE_EAL_PMD_PATH #define to a valid directory with built PMD shared libs. When it's set, DPDK dynamically loads all shared libraries inside. The drivers there depend on DPDK shared libs and fail to load in static SPDK builds, so we disable them altogether by unsetting RTE_EAL_PMD_PATH in the meson-generated config file - just like DPDK Makefiles did. EAL checks for RTE_EAL_PMD_PATH being empty and skips loading any external PMDs then. We do it for both static and shared libs. We specify all PMDs at build time for now, so there's just no need to load them dynamically. We have three more hacks in our submodule: * disable building dpdk apps by commenting-out a line in dpdk/meson.build * disable building unnecessary libs (build everything that spdk *may* need) * build isa-l compress pmd with `-L[...] -lisal`. DPDK expects to find libisal with pkg-config. We don't want to prepare a pkg-config file, so comment-out a failing check in another meson.build file and provide isa-l through CFLAGS and LDFLAGS. We also need to make some changes to our test/external_code. First of all, -ldpdk is no more. Meson build generates a pkg-config file with all libs, but we'll switch to it in a separate patch - for now just specify all -lrte_ libs one by one. -Wl,--no-as-needed has to be added to some test cases, otherwise rte_mempool_ring isn't loaded. We don't use any APIs from this library, it only has a static constructor that provides a few callbacks used by rte_mempool_create(). Also, since DPDK now builds both static and shared libraries, we need to add -Wl,-Bstatic to force using static libswhere required. It's only needed for DPDK libs, but we use it for SPDK libs as well since there's no harm. As for performance: $ ./configure --enable-debug --with-crypto --with-reduce $ time make -j40 -C dpdkbuild all with meson: real 0m8.287s user 1m7.983s sys 0m10.548s before, with the old DPDK makefiles: real 0m20.232s user 0m55.921s sys 0m16.491s The subsequent builds are much faster too: $ time make -j40 -C dpdkbuild all meson: real 0m0.876s user 0m0.663s sys 0m0.217s makefiles: real 0m10.150s user 0m11.740s sys 0m6.772s [1] http://inbox.dpdk.org/dev/1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org/ Change-Id: Ic65db563014100bafb12e61ee0530cc2ae64401d Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1440 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2020-03-23 16:55:08 +00:00
# the drivers we use
DPDK_DRIVERS = bus bus/pci bus/vdev mempool/ring
dpdkbuild: fix CONFIG_RTE_BUILD_SHARED_LIB We commented out this build option in our DPDK fork, but DPDK makefiles check its value specifically against 'n' to set linking flags properly. It's currently unset, so it fails both == 'n' and == 'y' checks, which fails the build. Shared lib build has some issues on FreeBSD right now, so to fix the immediate problem, just define the shared lib option to 'n' for now. This matches the original behavior. We've always built DPDK as a static library. Change-Id: I5a880b777153cc169c3a135d412aa2014f4de8e0 Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/463290 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Paul Luse <paul.e.luse@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com>
2019-07-26 08:59:39 +00:00
build/dpdk: disable unused libraries from DPDK submodule Most DPDK libraries are not required for SPDK. Those can be disabled for submodule. Starting with patch https://review.spdk.io/gerrit/c/spdk/dpdk/+/10540 it is possible to not compile a lot of the DPDK libs. This reduces the build time for DPDK submodule. Historically it was done on DPDK submodule side: https://review.spdk.io/gerrit/c/spdk/dpdk/+/2578 Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Change-Id: I4510baf2773fe15835e705bad42cf3ba9f35c418 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/10506 Reviewed-by: Konrad Sztyber <konrad.sztyber@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
2021-12-01 10:12:56 +00:00
# Core DPDK libs
DPDK_LIBS = eal ring mempool pci
DPDK_LIBS += kvargs telemetry
# Governor required libs
DPDK_LIBS += power timer ethdev net
mk: Build crypto/qat when --with-reduce is specified DPDK compilation fails when we configure SPDK using --with-reduce: ../drivers/common/qat/qat_qp.c:18:10: fatal error: qat_sym.h: No such file or directory #include "qat_sym.h" ^~~~~~~~~~~ But when SPDK is also configured using --with-crypto, DPDK is built successfully --with-crypto enables build of crypto/qat driver and meson config for this driver adds dpdk/driver/crypto/qat directory to QAT includes. This directory contains the missing qat_sym.h and qat_sym_pmd.h files. Group common drivers required by crypto/reduce Fixes issue #1529 Change-Id: I7a53411798091e9a3c16442f3951ff73138d7337 Signed-off-by: Alexey Marchuk <alexeymar@mellanox.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/4179 Reviewed-by: Paul Luse <paul.e.luse@intel.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Community-CI: Broadcom CI Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
2020-09-11 12:27:59 +00:00
# common crypto/reduce drivers
ifeq ($(findstring y,$(CONFIG_CRYPTO)$(CONFIG_REDUCE)),y)
DPDK_DRIVERS += crypto/qat compress/qat common/qat
endif
dpdkbuild: build igb_uio independent of crypto This driver has more generic use cases than just for the crypto driver. See github issues 594 and 210. Change-Id: I7adcb058418a9b56ffa150366584b22b38eb8398 Signed-off-by: Seth Howell <seth.howell@intel.com> Reviewed-on: https://review.gerrithub.io/c/444123 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com> Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com>
2019-02-11 20:24:42 +00:00
ifeq ($(CONFIG_CRYPTO),y)
dpdkbuild: fix name of crypto pmd for DPDK 21.11 crypto/aesni_mb is renamed to crypto/ipsec_mb, starting with DPDK 21.11. Patch below remedied most of the changes required: (089cbda8)autobuild: Adjusting crypto build for latest DPDK (21.11) Yet it missed changing the driver name when using submodule. Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Change-Id: Iec23d35e2a64ddab975b394a23e72af1a11c7b6e Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/10453 Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Aleksey Marchuk <alexeymar@mellanox.com>
2021-11-29 14:47:00 +00:00
DPDK_DRIVERS += crypto crypto/ipsec_mb
# aesni_mb is name of the PMD in DPDK 21.08 and earlier
DPDK_DRIVERS += crypto/aesni_mb
ipsec_mb: use EXTRA_CFLAGS to point DPDK to intel-ipsec-mb submodule This allows us to remove the requirement to install intel-ipsec-mb to system directories. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I579655a98b515cf148b7cd17823a9bb541ea6ad7 Reviewed-on: https://review.gerrithub.io/c/440785 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Seth Howell <seth.howell5141@gmail.com> Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com>
2019-01-13 20:28:21 +00:00
DPDK_CFLAGS += -I$(IPSEC_MB_DIR)
dpdkbuild: specify ldflags In DPDK 19.05 there's a new test app which we obviously don't need to build, but we have no way not to, as it's built together with a library that we do need. That app may try to link with crypto and compress PMDs, which require IPSec and ISA-L respectively. If those were not installed on the system, the linking would fail. We fix it by providing DPDK with extra -L/path/to/[...] Change-Id: I652efb669d10d2d03d0f643ce539404c1f0e38c4 Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/455825 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
2019-05-27 12:03:51 +00:00
DPDK_LDFLAGS += -L$(IPSEC_MB_DIR)
build: add intel-ipsec-mb submodule This is a dependency of the DPDK crypto framework. The submodule is currently set to our SPDK fork of the ipsec library which is based off of the library v0.48 tag, as required by DPDK plus one minor Makefile change on the 'spdk' branch of the fork. Also added is a configure option '--with-crypto' and the associated conditionals for building DPDK with or without the library dependency. The crypto vbdev patch will use this same configure option to determine DPDK opts as well as whether the crypto vbdev should be built or not. Change-Id: Ib1cfd15b63b29acf3c2f7345d0d7edfd94716620 Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com> Signed-off-by: paul luse <paul.e.luse@intel.com> Reviewed-on: https://review.gerrithub.io/404983 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com> Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
2018-03-22 23:24:14 +00:00
endif
bdev/compress: Add configure option and build dependencies Includes the required DPDK dependencies for SPDK block Reduce aka Compression. Change-Id: Ic1ea3cbeb9373a7700f6f0c2a3194d65d6a34a41 Signed-off-by: paul luse <paul.e.luse@intel.com> Reviewed-on: https://review.gerrithub.io/c/429523 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com>
2018-10-15 20:46:41 +00:00
ifeq ($(CONFIG_REDUCE),y)
mk: Build crypto/qat when --with-reduce is specified DPDK compilation fails when we configure SPDK using --with-reduce: ../drivers/common/qat/qat_qp.c:18:10: fatal error: qat_sym.h: No such file or directory #include "qat_sym.h" ^~~~~~~~~~~ But when SPDK is also configured using --with-crypto, DPDK is built successfully --with-crypto enables build of crypto/qat driver and meson config for this driver adds dpdk/driver/crypto/qat directory to QAT includes. This directory contains the missing qat_sym.h and qat_sym_pmd.h files. Group common drivers required by crypto/reduce Fixes issue #1529 Change-Id: I7a53411798091e9a3c16442f3951ff73138d7337 Signed-off-by: Alexey Marchuk <alexeymar@mellanox.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/4179 Reviewed-by: Paul Luse <paul.e.luse@intel.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Community-CI: Broadcom CI Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
2020-09-11 12:27:59 +00:00
DPDK_DRIVERS += compress compress/isal
mk: Enable build of mlx5_pci compress PMD This PMD is availabe for BlueField2 DPU. It requires libmlx5, so configure file is updated to check if this library exists Change-Id: Ic0cfbfdf24af393381667435009fb6afc49d9181 Signed-off-by: Alexey Marchuk <alexeymar@mellanox.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/8780 Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2021-06-15 13:25:07 +00:00
ifeq ($(CONFIG_REDUCE_MLX5),y)
dpdk: update DPDK to 21.08 version Update submodule DPDK to version 21.08 and modify CHANGELOG. Added bus auxiliary dependencies to dpdkbuild/Makefile and lib/env_dpdk/env.mk. This dependency was introduced in DPDK 21.08. Change-Id: I72d9fde456583dc129f4c7fced4f10875bbc38e2 Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/9211 Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Aleksey Marchuk <alexeymar@mellanox.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
2021-08-18 07:59:44 +00:00
DPDK_DRIVERS += common/mlx5 compress/mlx5 bus/auxiliary
mk: Enable build of mlx5_pci compress PMD This PMD is availabe for BlueField2 DPU. It requires libmlx5, so configure file is updated to check if this library exists Change-Id: Ic0cfbfdf24af393381667435009fb6afc49d9181 Signed-off-by: Alexey Marchuk <alexeymar@mellanox.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/8780 Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2021-06-15 13:25:07 +00:00
endif
bdev/crypto: add /include symlink for ISAL Currently we only include the dir just above ISA-L which allows the isal.h file includes to be found however DPDK can't find isa-l.h at that location because its one level deeper. By adding a symlink in the isa-l subdir we can redirect DPDK to find the isa-l header files. Change-Id: Ieeabd4273bade0241db5581764b2169103f9770f Signed-off-by: paul luse <paul.e.luse@intel.com> Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/445767 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com>
2019-02-21 18:57:24 +00:00
DPDK_CFLAGS += -I$(ISAL_DIR)
dpdkbuild: build dpdk with meson+ninja Makefile support in DPDK was deprecated and will be removed soon, so switch to the officially supported way of building DPDK - with meson and ninja. Two new tools. Basically, our Makefiles will invoke meson+ninja for DPDK, no other SPDK components are affected. Apparently DPDK wanted to move away from an octopus-like config system and the ideology behind meson configuration is simple now: build everything by default. Some PMDs can be explicitly disabled with meson command line, but all libraries (both static and shared versions) and test apps are built unconditionally. How long does it take to build minimal DPDK with meson? Too much. On my machine half of the total build time is spent on libraries we don't need at all. (I have some hacks up my sleeve to disable building those libraries - see the subsequent patch.) As for the official way of building a minimal DPDK, there was a patch [1] on dpdk mailing list to introduce more specific configuration, but it was rejected: > We talked about this a few times in the past, and it was actually one > of the design goals to _avoid_ replicating the octopus-like config > system of the makefiles. That's because it makes the test matrix > insanely complicated, not to mention the harm to user friendliness, > among other things. > > If someone doesn't want to use a PMD, they can just avoid installing it > - it's simple enough. > > Sorry, but from me it's a very strong NACK. Let's not follow that direction, hack the DPDK build system instead. As for advantages of meson+ninja over Makefiles? I can't find any. It's another build system that does a lot for you with some functions, magic options, and a built-in dependency system. It seems nice if you know the syntax, but it's another component that you need to learn, debug, and possibly find bugs in (there's a lot of github issues open for meson). I would compare it to CMake. As for changes in this patch: rather that explicitly disabling PMDs we don't need, specify a list of PMDs we do need and disable everything else found in ./dpdk/drivers/*. This way we won't have to disable the new PMDs as they're added to DPDK. Meson configuration also sets RTE_EAL_PMD_PATH #define to a valid directory with built PMD shared libs. When it's set, DPDK dynamically loads all shared libraries inside. The drivers there depend on DPDK shared libs and fail to load in static SPDK builds, so we disable them altogether by unsetting RTE_EAL_PMD_PATH in the meson-generated config file - just like DPDK Makefiles did. EAL checks for RTE_EAL_PMD_PATH being empty and skips loading any external PMDs then. We do it for both static and shared libs. We specify all PMDs at build time for now, so there's just no need to load them dynamically. We have three more hacks in our submodule: * disable building dpdk apps by commenting-out a line in dpdk/meson.build * disable building unnecessary libs (build everything that spdk *may* need) * build isa-l compress pmd with `-L[...] -lisal`. DPDK expects to find libisal with pkg-config. We don't want to prepare a pkg-config file, so comment-out a failing check in another meson.build file and provide isa-l through CFLAGS and LDFLAGS. We also need to make some changes to our test/external_code. First of all, -ldpdk is no more. Meson build generates a pkg-config file with all libs, but we'll switch to it in a separate patch - for now just specify all -lrte_ libs one by one. -Wl,--no-as-needed has to be added to some test cases, otherwise rte_mempool_ring isn't loaded. We don't use any APIs from this library, it only has a static constructor that provides a few callbacks used by rte_mempool_create(). Also, since DPDK now builds both static and shared libraries, we need to add -Wl,-Bstatic to force using static libswhere required. It's only needed for DPDK libs, but we use it for SPDK libs as well since there's no harm. As for performance: $ ./configure --enable-debug --with-crypto --with-reduce $ time make -j40 -C dpdkbuild all with meson: real 0m8.287s user 1m7.983s sys 0m10.548s before, with the old DPDK makefiles: real 0m20.232s user 0m55.921s sys 0m16.491s The subsequent builds are much faster too: $ time make -j40 -C dpdkbuild all meson: real 0m0.876s user 0m0.663s sys 0m0.217s makefiles: real 0m10.150s user 0m11.740s sys 0m6.772s [1] http://inbox.dpdk.org/dev/1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org/ Change-Id: Ic65db563014100bafb12e61ee0530cc2ae64401d Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1440 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2020-03-23 16:55:08 +00:00
DPDK_LDFLAGS += -L$(ISAL_DIR)/.libs -lisal
dpdkbuild: build rte_vhost only if SPDK vhost is built DPDK rte_vhost has some nasty dependencies which we don't necessarily want to resolve if we don't want to use vhost at all. We'll now build rte_vhost only if SPDK vhost is built. Change-Id: Icb830b11cc128eb8ee357dad94dfe62ac0cf2cce Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/460529 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
2019-07-04 14:36:06 +00:00
endif
build/dpdk: disable unused libraries from DPDK submodule Most DPDK libraries are not required for SPDK. Those can be disabled for submodule. Starting with patch https://review.spdk.io/gerrit/c/spdk/dpdk/+/10540 it is possible to not compile a lot of the DPDK libs. This reduces the build time for DPDK submodule. Historically it was done on DPDK submodule side: https://review.spdk.io/gerrit/c/spdk/dpdk/+/2578 Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Change-Id: I4510baf2773fe15835e705bad42cf3ba9f35c418 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/10506 Reviewed-by: Konrad Sztyber <konrad.sztyber@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
2021-12-01 10:12:56 +00:00
# crypto & compress deps
DPDK_LIBS += reorder cryptodev
DPDK_LIBS += compressdev
DPDK_LIBS += security
# vhost and deps
DPDK_LIBS += cryptodev mbuf cmdline meter hash vhost
# raid5 deps
DPDK_LIBS += hash rcu
dpdkbuild: build dpdk with meson+ninja Makefile support in DPDK was deprecated and will be removed soon, so switch to the officially supported way of building DPDK - with meson and ninja. Two new tools. Basically, our Makefiles will invoke meson+ninja for DPDK, no other SPDK components are affected. Apparently DPDK wanted to move away from an octopus-like config system and the ideology behind meson configuration is simple now: build everything by default. Some PMDs can be explicitly disabled with meson command line, but all libraries (both static and shared versions) and test apps are built unconditionally. How long does it take to build minimal DPDK with meson? Too much. On my machine half of the total build time is spent on libraries we don't need at all. (I have some hacks up my sleeve to disable building those libraries - see the subsequent patch.) As for the official way of building a minimal DPDK, there was a patch [1] on dpdk mailing list to introduce more specific configuration, but it was rejected: > We talked about this a few times in the past, and it was actually one > of the design goals to _avoid_ replicating the octopus-like config > system of the makefiles. That's because it makes the test matrix > insanely complicated, not to mention the harm to user friendliness, > among other things. > > If someone doesn't want to use a PMD, they can just avoid installing it > - it's simple enough. > > Sorry, but from me it's a very strong NACK. Let's not follow that direction, hack the DPDK build system instead. As for advantages of meson+ninja over Makefiles? I can't find any. It's another build system that does a lot for you with some functions, magic options, and a built-in dependency system. It seems nice if you know the syntax, but it's another component that you need to learn, debug, and possibly find bugs in (there's a lot of github issues open for meson). I would compare it to CMake. As for changes in this patch: rather that explicitly disabling PMDs we don't need, specify a list of PMDs we do need and disable everything else found in ./dpdk/drivers/*. This way we won't have to disable the new PMDs as they're added to DPDK. Meson configuration also sets RTE_EAL_PMD_PATH #define to a valid directory with built PMD shared libs. When it's set, DPDK dynamically loads all shared libraries inside. The drivers there depend on DPDK shared libs and fail to load in static SPDK builds, so we disable them altogether by unsetting RTE_EAL_PMD_PATH in the meson-generated config file - just like DPDK Makefiles did. EAL checks for RTE_EAL_PMD_PATH being empty and skips loading any external PMDs then. We do it for both static and shared libs. We specify all PMDs at build time for now, so there's just no need to load them dynamically. We have three more hacks in our submodule: * disable building dpdk apps by commenting-out a line in dpdk/meson.build * disable building unnecessary libs (build everything that spdk *may* need) * build isa-l compress pmd with `-L[...] -lisal`. DPDK expects to find libisal with pkg-config. We don't want to prepare a pkg-config file, so comment-out a failing check in another meson.build file and provide isa-l through CFLAGS and LDFLAGS. We also need to make some changes to our test/external_code. First of all, -ldpdk is no more. Meson build generates a pkg-config file with all libs, but we'll switch to it in a separate patch - for now just specify all -lrte_ libs one by one. -Wl,--no-as-needed has to be added to some test cases, otherwise rte_mempool_ring isn't loaded. We don't use any APIs from this library, it only has a static constructor that provides a few callbacks used by rte_mempool_create(). Also, since DPDK now builds both static and shared libraries, we need to add -Wl,-Bstatic to force using static libswhere required. It's only needed for DPDK libs, but we use it for SPDK libs as well since there's no harm. As for performance: $ ./configure --enable-debug --with-crypto --with-reduce $ time make -j40 -C dpdkbuild all with meson: real 0m8.287s user 1m7.983s sys 0m10.548s before, with the old DPDK makefiles: real 0m20.232s user 0m55.921s sys 0m16.491s The subsequent builds are much faster too: $ time make -j40 -C dpdkbuild all meson: real 0m0.876s user 0m0.663s sys 0m0.217s makefiles: real 0m10.150s user 0m11.740s sys 0m6.772s [1] http://inbox.dpdk.org/dev/1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org/ Change-Id: Ic65db563014100bafb12e61ee0530cc2ae64401d Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1440 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2020-03-23 16:55:08 +00:00
DPDK_OPTS += -Dmachine=$(TARGET_ARCHITECTURE)
build: add dpdk as a submodule This will allow a git clone to default to an SPDK-specific version of the DPDK repository. Users can still override to use a separate DPDK repository/installation with the --with-dpdk configure script options. While here, remove gzip option for the git-archive operations in autopackage.sh. We need to add a git-archive for the DPDK submodule if we are using it, and compressing at -9 adds a lot of unnecessary time. Since we are not archiving these packages, there is no need to compress them. Also explicitly disable coverage and ubsan for the autopackage build, since this build is only to test compilation and is not actually used for any test execution. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I3cf8a2ed984003a175cdece6542636ede8cb2479
2017-05-08 22:07:13 +00:00
make: add cross-compilation support There might be a need for user to cross-compile SPDK for other platforms than native. Since DPDK supports cross-compilation already, only enablement of cross-compilation for SPDK is missing. This patch aims to provide the user with additional option to configure script that works similar to what DPDK already provides. To enable cross-compilation run ./configure.sh with additional --cross-prefix parameter. The parameter should work in similar manner to DPDK CROSS parameter and specifies prefix of cross-compiler defined in PATH variable. Note: To cross-compile, toolchain must have SPDK dependencies such as e.g. Libaio. Signed-off-by: Amelia Blachuciak <amelia.blachuciak@intel.com> Change-Id: Ia7cb879d39d624552cad1af98a563070ea7676b2 Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/460977 Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Reviewed-by: Paul Luse <paul.e.luse@intel.com> Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
2019-07-09 12:40:41 +00:00
ifneq ($(CONFIG_CROSS_PREFIX),)
dpdkbuild: add support for mingw cross build If CONFIG_CROSS_PREFIX includes 'mingw', then specify --cross-file 'config/x86/cross-mingw' which is used as part of regular DPDK testing, so is being maintained. For any other non-null prefix, default to the current error message that automatic cross builds are not supported. Tested by running ./configure --cross-prefix=x86_64-w64-mingw32 and verified that 'make' in dpdkbuild used the cross tools. Signed-off-by: Nick Connolly <nick.connolly@mayadata.io> Change-Id: I75c401dfe8422f6c5f1bbe631695e7ae6118f723 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/6530 Community-CI: Broadcom CI Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Aleksey Marchuk <alexeymar@mellanox.com>
2021-02-23 10:13:16 +00:00
ifeq ($(findstring mingw,$(CONFIG_CROSS_PREFIX)),mingw)
DPDK_OPTS += --cross-file $(SPDK_ROOT_DIR)/dpdk/config/x86/cross-mingw
else
dpdkbuild: build dpdk with meson+ninja Makefile support in DPDK was deprecated and will be removed soon, so switch to the officially supported way of building DPDK - with meson and ninja. Two new tools. Basically, our Makefiles will invoke meson+ninja for DPDK, no other SPDK components are affected. Apparently DPDK wanted to move away from an octopus-like config system and the ideology behind meson configuration is simple now: build everything by default. Some PMDs can be explicitly disabled with meson command line, but all libraries (both static and shared versions) and test apps are built unconditionally. How long does it take to build minimal DPDK with meson? Too much. On my machine half of the total build time is spent on libraries we don't need at all. (I have some hacks up my sleeve to disable building those libraries - see the subsequent patch.) As for the official way of building a minimal DPDK, there was a patch [1] on dpdk mailing list to introduce more specific configuration, but it was rejected: > We talked about this a few times in the past, and it was actually one > of the design goals to _avoid_ replicating the octopus-like config > system of the makefiles. That's because it makes the test matrix > insanely complicated, not to mention the harm to user friendliness, > among other things. > > If someone doesn't want to use a PMD, they can just avoid installing it > - it's simple enough. > > Sorry, but from me it's a very strong NACK. Let's not follow that direction, hack the DPDK build system instead. As for advantages of meson+ninja over Makefiles? I can't find any. It's another build system that does a lot for you with some functions, magic options, and a built-in dependency system. It seems nice if you know the syntax, but it's another component that you need to learn, debug, and possibly find bugs in (there's a lot of github issues open for meson). I would compare it to CMake. As for changes in this patch: rather that explicitly disabling PMDs we don't need, specify a list of PMDs we do need and disable everything else found in ./dpdk/drivers/*. This way we won't have to disable the new PMDs as they're added to DPDK. Meson configuration also sets RTE_EAL_PMD_PATH #define to a valid directory with built PMD shared libs. When it's set, DPDK dynamically loads all shared libraries inside. The drivers there depend on DPDK shared libs and fail to load in static SPDK builds, so we disable them altogether by unsetting RTE_EAL_PMD_PATH in the meson-generated config file - just like DPDK Makefiles did. EAL checks for RTE_EAL_PMD_PATH being empty and skips loading any external PMDs then. We do it for both static and shared libs. We specify all PMDs at build time for now, so there's just no need to load them dynamically. We have three more hacks in our submodule: * disable building dpdk apps by commenting-out a line in dpdk/meson.build * disable building unnecessary libs (build everything that spdk *may* need) * build isa-l compress pmd with `-L[...] -lisal`. DPDK expects to find libisal with pkg-config. We don't want to prepare a pkg-config file, so comment-out a failing check in another meson.build file and provide isa-l through CFLAGS and LDFLAGS. We also need to make some changes to our test/external_code. First of all, -ldpdk is no more. Meson build generates a pkg-config file with all libs, but we'll switch to it in a separate patch - for now just specify all -lrte_ libs one by one. -Wl,--no-as-needed has to be added to some test cases, otherwise rte_mempool_ring isn't loaded. We don't use any APIs from this library, it only has a static constructor that provides a few callbacks used by rte_mempool_create(). Also, since DPDK now builds both static and shared libraries, we need to add -Wl,-Bstatic to force using static libswhere required. It's only needed for DPDK libs, but we use it for SPDK libs as well since there's no harm. As for performance: $ ./configure --enable-debug --with-crypto --with-reduce $ time make -j40 -C dpdkbuild all with meson: real 0m8.287s user 1m7.983s sys 0m10.548s before, with the old DPDK makefiles: real 0m20.232s user 0m55.921s sys 0m16.491s The subsequent builds are much faster too: $ time make -j40 -C dpdkbuild all meson: real 0m0.876s user 0m0.663s sys 0m0.217s makefiles: real 0m10.150s user 0m11.740s sys 0m6.772s [1] http://inbox.dpdk.org/dev/1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org/ Change-Id: Ic65db563014100bafb12e61ee0530cc2ae64401d Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1440 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2020-03-23 16:55:08 +00:00
$(error Automatic DPDK cross build is not supported. Please compile DPDK manually \
with e.g. `meson build --cross-file config/arm/arm64_armv8_linux_gcc`)
build: add dpdk as a submodule This will allow a git clone to default to an SPDK-specific version of the DPDK repository. Users can still override to use a separate DPDK repository/installation with the --with-dpdk configure script options. While here, remove gzip option for the git-archive operations in autopackage.sh. We need to add a git-archive for the DPDK submodule if we are using it, and compressing at -9 adds a lot of unnecessary time. Since we are not archiving these packages, there is no need to compress them. Also explicitly disable coverage and ubsan for the autopackage build, since this build is only to test compilation and is not actually used for any test execution. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I3cf8a2ed984003a175cdece6542636ede8cb2479
2017-05-08 22:07:13 +00:00
endif
dpdkbuild: add support for mingw cross build If CONFIG_CROSS_PREFIX includes 'mingw', then specify --cross-file 'config/x86/cross-mingw' which is used as part of regular DPDK testing, so is being maintained. For any other non-null prefix, default to the current error message that automatic cross builds are not supported. Tested by running ./configure --cross-prefix=x86_64-w64-mingw32 and verified that 'make' in dpdkbuild used the cross tools. Signed-off-by: Nick Connolly <nick.connolly@mayadata.io> Change-Id: I75c401dfe8422f6c5f1bbe631695e7ae6118f723 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/6530 Community-CI: Broadcom CI Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Aleksey Marchuk <alexeymar@mellanox.com>
2021-02-23 10:13:16 +00:00
endif
build: add dpdk as a submodule This will allow a git clone to default to an SPDK-specific version of the DPDK repository. Users can still override to use a separate DPDK repository/installation with the --with-dpdk configure script options. While here, remove gzip option for the git-archive operations in autopackage.sh. We need to add a git-archive for the DPDK submodule if we are using it, and compressing at -9 adds a lot of unnecessary time. Since we are not archiving these packages, there is no need to compress them. Also explicitly disable coverage and ubsan for the autopackage build, since this build is only to test compilation and is not actually used for any test execution. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I3cf8a2ed984003a175cdece6542636ede8cb2479
2017-05-08 22:07:13 +00:00
ipsec_mb: use EXTRA_CFLAGS to point DPDK to intel-ipsec-mb submodule This allows us to remove the requirement to install intel-ipsec-mb to system directories. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I579655a98b515cf148b7cd17823a9bb541ea6ad7 Reviewed-on: https://review.gerrithub.io/c/440785 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Seth Howell <seth.howell5141@gmail.com> Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com>
2019-01-13 20:28:21 +00:00
DPDK_CFLAGS += -fPIC
build: add dpdk as a submodule This will allow a git clone to default to an SPDK-specific version of the DPDK repository. Users can still override to use a separate DPDK repository/installation with the --with-dpdk configure script options. While here, remove gzip option for the git-archive operations in autopackage.sh. We need to add a git-archive for the DPDK submodule if we are using it, and compressing at -9 adds a lot of unnecessary time. Since we are not archiving these packages, there is no need to compress them. Also explicitly disable coverage and ubsan for the autopackage build, since this build is only to test compilation and is not actually used for any test execution. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I3cf8a2ed984003a175cdece6542636ede8cb2479
2017-05-08 22:07:13 +00:00
dpdkbuild: pass along -Werror config from SPDK Change-Id: I0cbf2aa53dcdb82cc8bbdf3b47b5ae301a1191ec Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com> Reviewed-on: https://review.gerrithub.io/363489 Tested-by: SPDK Automated Test System <sys_sgsw@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com>
2017-06-02 06:16:33 +00:00
ifeq ($(CONFIG_WERROR),y)
DPDK_CFLAGS += -Werror
else
DPDK_CFLAGS += -Wno-error
endif
configure: add --enable-cet to build with CET support Intel Control-flow Enforcement Technology (CET) is a processor feature that blocks return/jump-oriented programming (ROP) attacks. It is currently only supported on Tiger Lake client processors, but will be available on other processors in the future. CET requires toolchain support. gcc8 does support it. For now, this will opt-in only at least until the technology is available on server processors. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I8c7f882eeeaed26484c31dc0d67d5cc42baeaa2d Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/5921 Community-CI: Broadcom CI Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
2021-01-14 11:06:33 +00:00
ifeq ($(CONFIG_CET),y)
DPDK_CFLAGS += -fcf-protection
DPDK_LDFLAGS += -fcf-protection
endif
dpdkbuild: add EXTRA_DPDK_CFLAGS Users can specify this flag on the make command line to pass extra CFLAGS to the DPDK submodule build. This can be used with older compilers that are not supported by DPDK, and require -fno-strict-aliasing to compile. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: Ib99e64297402c07395c009987ccffe29099dffab Reviewed-on: https://review.gerrithub.io/429489 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Chandler-Test-Pool: SPDK Automated Test System <sys_sgsw@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Changpeng Liu <changpeng.liu@intel.com> Reviewed-by: <shahar.salzman@kaminario.com>
2018-10-15 15:47:28 +00:00
ifdef EXTRA_DPDK_CFLAGS
$(warning EXTRA_DPDK_CFLAGS defined, possibly to work around an unsupported compiler version)
$(shell sleep 1)
endif
# Allow users to specify EXTRA_DPDK_CFLAGS if they want to build DPDK using unsupported compiler versions
DPDK_CFLAGS += $(EXTRA_DPDK_CFLAGS)
make/dpdk: Correct compiler type detection This commit fixes compiler type detection to suppress warnings specific for gcc 10. Change-Id: I66264451792ff84a53001badc7c2f8a452d732af Signed-off-by: Alexey Marchuk <alexeymar@mellanox.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/3472 Reviewed-by: Changpeng Liu <changpeng.liu@intel.com> Reviewed-by: <dongx.yi@intel.com> Reviewed-by: Michal Berger <michalx.berger@intel.com> Reviewed-by: Vitaliy Mysak <vitaliy.mysak@intel.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
2020-07-22 06:13:01 +00:00
ifeq ($(CC_TYPE),gcc)
make/dpdk: Suppress GCC 10 warnings Suppres the following warnings which causes compilation errors: 1. gcc 10 complains on operations with zero size arrays in rte_cryptodev.c Suppress this warning by adding -Wno-stringop-overflow compilation flag 2. gcc 10 disables fcommon by default and complains on multiple definition of aesni_mb_logtype_driver symbol which is defined in header file and presented in sevral translation units. Add -fcommon compilation flag. Fixes issue #1493 Change-Id: I9241bf1fd78e86df6a6eb46b4ff787b2f7027b7d Signed-off-by: Alexey Marchuk <alexeymar@mellanox.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/3373 Community-CI: Broadcom CI Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
2020-07-16 09:59:30 +00:00
GCC_MAJOR = $(shell echo __GNUC__ | $(CC) -E -x c - | tail -n 1)
ifeq ($(shell test $(GCC_MAJOR) -ge 10 && echo 1), 1)
#1. gcc 10 complains on operations with zero size arrays in rte_cryptodev.c, so
#disable this warning
#2. gcc 10 disables fcommon by default and complains on multiple definition of
spelling: dpdkbuild Part of #2256 * parallel * several Change-Id: I192e204cdc34d541e5afdc59624b565abf1d668e Signed-off-by: Josh Soref <jsoref@gmail.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/10402 Community-CI: Mellanox Build Bot Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
2021-11-25 01:40:57 +00:00
#aesni_mb_logtype_driver symbol which is defined in header file and presented in several
make/dpdk: Suppress GCC 10 warnings Suppres the following warnings which causes compilation errors: 1. gcc 10 complains on operations with zero size arrays in rte_cryptodev.c Suppress this warning by adding -Wno-stringop-overflow compilation flag 2. gcc 10 disables fcommon by default and complains on multiple definition of aesni_mb_logtype_driver symbol which is defined in header file and presented in sevral translation units. Add -fcommon compilation flag. Fixes issue #1493 Change-Id: I9241bf1fd78e86df6a6eb46b4ff787b2f7027b7d Signed-off-by: Alexey Marchuk <alexeymar@mellanox.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/3373 Community-CI: Broadcom CI Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
2020-07-16 09:59:30 +00:00
#translation units
DPDK_CFLAGS += -Wno-stringop-overflow -fcommon
endif
endif
Makefile: don't override MAKEFLAGS in submake Apparently make doesn't like it: make[2]: warning: -jN forced in submake: disabling jobserver mode. We only did it because of scan-build - it detects a ton of issues (or false positives) in our dependencies. To disable it, we don't have to override MAKEFLAGS, but just CC - that's what we'll do now. Fixes #896 Change-Id: I5eea984d6bbfbf4caabdd704850fac840fed3524 Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/927 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
2019-08-26 07:02:35 +00:00
# Force-disable scan-build
SUB_CC = $(patsubst %ccc-analyzer,$(DEFAULT_CC),$(CC))
build/dpdk: disable unused libraries from DPDK submodule Most DPDK libraries are not required for SPDK. Those can be disabled for submodule. Starting with patch https://review.spdk.io/gerrit/c/spdk/dpdk/+/10540 it is possible to not compile a lot of the DPDK libs. This reduces the build time for DPDK submodule. Historically it was done on DPDK submodule side: https://review.spdk.io/gerrit/c/spdk/dpdk/+/2578 Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Change-Id: I4510baf2773fe15835e705bad42cf3ba9f35c418 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/10506 Reviewed-by: Konrad Sztyber <konrad.sztyber@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
2021-12-01 10:12:56 +00:00
DPDK_ALL_LIB_DIRS = $(shell find $(SPDK_ROOT_DIR)/dpdk/lib -mindepth 1 -maxdepth 1 -type d)
DPDK_ALL_LIBS = $(DPDK_ALL_LIB_DIRS:$(SPDK_ROOT_DIR)/dpdk/lib/%=%)
DPDK_DISABLED_LIBS = $(filter-out $(DPDK_LIBS),$(DPDK_ALL_LIBS))
dpdkbuild: improve portability Default to the more common Linux/GNU 'sed' edit in-place argument, unless the platform is FreeBSD. Tested by visually checking rte_build_config.h to confirm that the sed in-place worked correctly. Signed-off-by: Nick Connolly <nick.connolly@mayadata.io> Change-Id: I68be69658930fb20318ac3aa2413bbf4a358e9bc Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/6531 Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Community-CI: Broadcom CI Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
2021-02-23 10:30:26 +00:00
ifneq ($(OS),FreeBSD)
dpdkbuild: build dpdk with meson+ninja Makefile support in DPDK was deprecated and will be removed soon, so switch to the officially supported way of building DPDK - with meson and ninja. Two new tools. Basically, our Makefiles will invoke meson+ninja for DPDK, no other SPDK components are affected. Apparently DPDK wanted to move away from an octopus-like config system and the ideology behind meson configuration is simple now: build everything by default. Some PMDs can be explicitly disabled with meson command line, but all libraries (both static and shared versions) and test apps are built unconditionally. How long does it take to build minimal DPDK with meson? Too much. On my machine half of the total build time is spent on libraries we don't need at all. (I have some hacks up my sleeve to disable building those libraries - see the subsequent patch.) As for the official way of building a minimal DPDK, there was a patch [1] on dpdk mailing list to introduce more specific configuration, but it was rejected: > We talked about this a few times in the past, and it was actually one > of the design goals to _avoid_ replicating the octopus-like config > system of the makefiles. That's because it makes the test matrix > insanely complicated, not to mention the harm to user friendliness, > among other things. > > If someone doesn't want to use a PMD, they can just avoid installing it > - it's simple enough. > > Sorry, but from me it's a very strong NACK. Let's not follow that direction, hack the DPDK build system instead. As for advantages of meson+ninja over Makefiles? I can't find any. It's another build system that does a lot for you with some functions, magic options, and a built-in dependency system. It seems nice if you know the syntax, but it's another component that you need to learn, debug, and possibly find bugs in (there's a lot of github issues open for meson). I would compare it to CMake. As for changes in this patch: rather that explicitly disabling PMDs we don't need, specify a list of PMDs we do need and disable everything else found in ./dpdk/drivers/*. This way we won't have to disable the new PMDs as they're added to DPDK. Meson configuration also sets RTE_EAL_PMD_PATH #define to a valid directory with built PMD shared libs. When it's set, DPDK dynamically loads all shared libraries inside. The drivers there depend on DPDK shared libs and fail to load in static SPDK builds, so we disable them altogether by unsetting RTE_EAL_PMD_PATH in the meson-generated config file - just like DPDK Makefiles did. EAL checks for RTE_EAL_PMD_PATH being empty and skips loading any external PMDs then. We do it for both static and shared libs. We specify all PMDs at build time for now, so there's just no need to load them dynamically. We have three more hacks in our submodule: * disable building dpdk apps by commenting-out a line in dpdk/meson.build * disable building unnecessary libs (build everything that spdk *may* need) * build isa-l compress pmd with `-L[...] -lisal`. DPDK expects to find libisal with pkg-config. We don't want to prepare a pkg-config file, so comment-out a failing check in another meson.build file and provide isa-l through CFLAGS and LDFLAGS. We also need to make some changes to our test/external_code. First of all, -ldpdk is no more. Meson build generates a pkg-config file with all libs, but we'll switch to it in a separate patch - for now just specify all -lrte_ libs one by one. -Wl,--no-as-needed has to be added to some test cases, otherwise rte_mempool_ring isn't loaded. We don't use any APIs from this library, it only has a static constructor that provides a few callbacks used by rte_mempool_create(). Also, since DPDK now builds both static and shared libraries, we need to add -Wl,-Bstatic to force using static libswhere required. It's only needed for DPDK libs, but we use it for SPDK libs as well since there's no harm. As for performance: $ ./configure --enable-debug --with-crypto --with-reduce $ time make -j40 -C dpdkbuild all with meson: real 0m8.287s user 1m7.983s sys 0m10.548s before, with the old DPDK makefiles: real 0m20.232s user 0m55.921s sys 0m16.491s The subsequent builds are much faster too: $ time make -j40 -C dpdkbuild all meson: real 0m0.876s user 0m0.663s sys 0m0.217s makefiles: real 0m10.150s user 0m11.740s sys 0m6.772s [1] http://inbox.dpdk.org/dev/1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org/ Change-Id: Ic65db563014100bafb12e61ee0530cc2ae64401d Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1440 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2020-03-23 16:55:08 +00:00
SED_INPLACE_FLAG = "-i"
MESON_PREFIX = $(SPDK_ROOT_DIR)/dpdk/build
else
SED_INPLACE_FLAG = "-i ''"
MESON_PREFIX = "/"
endif
# Some ninja versions come with a (broken?) jobserver which defaults to use
# only 1 thread for the build. We workaround this by specifying -j to ninja
# with the same value as top-makefile. This is OK as long as DPDK is not built
spelling: dpdkbuild Part of #2256 * parallel * several Change-Id: I192e204cdc34d541e5afdc59624b565abf1d668e Signed-off-by: Josh Soref <jsoref@gmail.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/10402 Community-CI: Mellanox Build Bot Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
2021-11-25 01:40:57 +00:00
# in parallel with anything else, which is the case for now.
dpdkbuild: build dpdk with meson+ninja Makefile support in DPDK was deprecated and will be removed soon, so switch to the officially supported way of building DPDK - with meson and ninja. Two new tools. Basically, our Makefiles will invoke meson+ninja for DPDK, no other SPDK components are affected. Apparently DPDK wanted to move away from an octopus-like config system and the ideology behind meson configuration is simple now: build everything by default. Some PMDs can be explicitly disabled with meson command line, but all libraries (both static and shared versions) and test apps are built unconditionally. How long does it take to build minimal DPDK with meson? Too much. On my machine half of the total build time is spent on libraries we don't need at all. (I have some hacks up my sleeve to disable building those libraries - see the subsequent patch.) As for the official way of building a minimal DPDK, there was a patch [1] on dpdk mailing list to introduce more specific configuration, but it was rejected: > We talked about this a few times in the past, and it was actually one > of the design goals to _avoid_ replicating the octopus-like config > system of the makefiles. That's because it makes the test matrix > insanely complicated, not to mention the harm to user friendliness, > among other things. > > If someone doesn't want to use a PMD, they can just avoid installing it > - it's simple enough. > > Sorry, but from me it's a very strong NACK. Let's not follow that direction, hack the DPDK build system instead. As for advantages of meson+ninja over Makefiles? I can't find any. It's another build system that does a lot for you with some functions, magic options, and a built-in dependency system. It seems nice if you know the syntax, but it's another component that you need to learn, debug, and possibly find bugs in (there's a lot of github issues open for meson). I would compare it to CMake. As for changes in this patch: rather that explicitly disabling PMDs we don't need, specify a list of PMDs we do need and disable everything else found in ./dpdk/drivers/*. This way we won't have to disable the new PMDs as they're added to DPDK. Meson configuration also sets RTE_EAL_PMD_PATH #define to a valid directory with built PMD shared libs. When it's set, DPDK dynamically loads all shared libraries inside. The drivers there depend on DPDK shared libs and fail to load in static SPDK builds, so we disable them altogether by unsetting RTE_EAL_PMD_PATH in the meson-generated config file - just like DPDK Makefiles did. EAL checks for RTE_EAL_PMD_PATH being empty and skips loading any external PMDs then. We do it for both static and shared libs. We specify all PMDs at build time for now, so there's just no need to load them dynamically. We have three more hacks in our submodule: * disable building dpdk apps by commenting-out a line in dpdk/meson.build * disable building unnecessary libs (build everything that spdk *may* need) * build isa-l compress pmd with `-L[...] -lisal`. DPDK expects to find libisal with pkg-config. We don't want to prepare a pkg-config file, so comment-out a failing check in another meson.build file and provide isa-l through CFLAGS and LDFLAGS. We also need to make some changes to our test/external_code. First of all, -ldpdk is no more. Meson build generates a pkg-config file with all libs, but we'll switch to it in a separate patch - for now just specify all -lrte_ libs one by one. -Wl,--no-as-needed has to be added to some test cases, otherwise rte_mempool_ring isn't loaded. We don't use any APIs from this library, it only has a static constructor that provides a few callbacks used by rte_mempool_create(). Also, since DPDK now builds both static and shared libraries, we need to add -Wl,-Bstatic to force using static libswhere required. It's only needed for DPDK libs, but we use it for SPDK libs as well since there's no harm. As for performance: $ ./configure --enable-debug --with-crypto --with-reduce $ time make -j40 -C dpdkbuild all with meson: real 0m8.287s user 1m7.983s sys 0m10.548s before, with the old DPDK makefiles: real 0m20.232s user 0m55.921s sys 0m16.491s The subsequent builds are much faster too: $ time make -j40 -C dpdkbuild all meson: real 0m0.876s user 0m0.663s sys 0m0.217s makefiles: real 0m10.150s user 0m11.740s sys 0m6.772s [1] http://inbox.dpdk.org/dev/1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org/ Change-Id: Ic65db563014100bafb12e61ee0530cc2ae64401d Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1440 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2020-03-23 16:55:08 +00:00
ifeq ($(MAKE_PID),)
MAKE_PID := $(shell echo $$PPID)
endif
freebsd: Replace use of \s with [[:space:]] In latest 13.0 release of freebsd sed is not accepting \s anymore, hence it needs to be replaced. Note that only parts of the repo which are touched by freebsd during the tests are updated. Details https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253893 Signed-off-by: Michal Berger <michalx.berger@intel.com> Change-Id: I217208511af8f98e7033f8f24a343b5ca9c48825 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/7986 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Community-CI: Mellanox Build Bot Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com>
2021-05-20 21:16:24 +00:00
MAKE_NUMJOBS := $(shell ps T | sed -nE 's/[[:space:]]*$(MAKE_PID)[[:space:]].* (-j|--jobs=)( *[0-9]+).*/\1\2/p')
dpdkbuild: build dpdk with meson+ninja Makefile support in DPDK was deprecated and will be removed soon, so switch to the officially supported way of building DPDK - with meson and ninja. Two new tools. Basically, our Makefiles will invoke meson+ninja for DPDK, no other SPDK components are affected. Apparently DPDK wanted to move away from an octopus-like config system and the ideology behind meson configuration is simple now: build everything by default. Some PMDs can be explicitly disabled with meson command line, but all libraries (both static and shared versions) and test apps are built unconditionally. How long does it take to build minimal DPDK with meson? Too much. On my machine half of the total build time is spent on libraries we don't need at all. (I have some hacks up my sleeve to disable building those libraries - see the subsequent patch.) As for the official way of building a minimal DPDK, there was a patch [1] on dpdk mailing list to introduce more specific configuration, but it was rejected: > We talked about this a few times in the past, and it was actually one > of the design goals to _avoid_ replicating the octopus-like config > system of the makefiles. That's because it makes the test matrix > insanely complicated, not to mention the harm to user friendliness, > among other things. > > If someone doesn't want to use a PMD, they can just avoid installing it > - it's simple enough. > > Sorry, but from me it's a very strong NACK. Let's not follow that direction, hack the DPDK build system instead. As for advantages of meson+ninja over Makefiles? I can't find any. It's another build system that does a lot for you with some functions, magic options, and a built-in dependency system. It seems nice if you know the syntax, but it's another component that you need to learn, debug, and possibly find bugs in (there's a lot of github issues open for meson). I would compare it to CMake. As for changes in this patch: rather that explicitly disabling PMDs we don't need, specify a list of PMDs we do need and disable everything else found in ./dpdk/drivers/*. This way we won't have to disable the new PMDs as they're added to DPDK. Meson configuration also sets RTE_EAL_PMD_PATH #define to a valid directory with built PMD shared libs. When it's set, DPDK dynamically loads all shared libraries inside. The drivers there depend on DPDK shared libs and fail to load in static SPDK builds, so we disable them altogether by unsetting RTE_EAL_PMD_PATH in the meson-generated config file - just like DPDK Makefiles did. EAL checks for RTE_EAL_PMD_PATH being empty and skips loading any external PMDs then. We do it for both static and shared libs. We specify all PMDs at build time for now, so there's just no need to load them dynamically. We have three more hacks in our submodule: * disable building dpdk apps by commenting-out a line in dpdk/meson.build * disable building unnecessary libs (build everything that spdk *may* need) * build isa-l compress pmd with `-L[...] -lisal`. DPDK expects to find libisal with pkg-config. We don't want to prepare a pkg-config file, so comment-out a failing check in another meson.build file and provide isa-l through CFLAGS and LDFLAGS. We also need to make some changes to our test/external_code. First of all, -ldpdk is no more. Meson build generates a pkg-config file with all libs, but we'll switch to it in a separate patch - for now just specify all -lrte_ libs one by one. -Wl,--no-as-needed has to be added to some test cases, otherwise rte_mempool_ring isn't loaded. We don't use any APIs from this library, it only has a static constructor that provides a few callbacks used by rte_mempool_create(). Also, since DPDK now builds both static and shared libraries, we need to add -Wl,-Bstatic to force using static libswhere required. It's only needed for DPDK libs, but we use it for SPDK libs as well since there's no harm. As for performance: $ ./configure --enable-debug --with-crypto --with-reduce $ time make -j40 -C dpdkbuild all with meson: real 0m8.287s user 1m7.983s sys 0m10.548s before, with the old DPDK makefiles: real 0m20.232s user 0m55.921s sys 0m16.491s The subsequent builds are much faster too: $ time make -j40 -C dpdkbuild all meson: real 0m0.876s user 0m0.663s sys 0m0.217s makefiles: real 0m10.150s user 0m11.740s sys 0m6.772s [1] http://inbox.dpdk.org/dev/1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org/ Change-Id: Ic65db563014100bafb12e61ee0530cc2ae64401d Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1440 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2020-03-23 16:55:08 +00:00
all: $(SPDK_ROOT_DIR)/dpdk/build-tmp
$(Q)# DPDK doesn't handle nested make calls, so unset MAKEFLAGS
$(Q)env -u MAKEFLAGS ninja -C $(SPDK_ROOT_DIR)/dpdk/build-tmp $(MAKE_NUMJOBS)
$(Q) \
# Meson on FreeBSD sometimes appends --prefix value to the default DESTDIR (which is e.g. \
# /usr/local) instead of replacing it. --prefix needs to be an absolute path, so we set \
# it to / and then set DESTDIR directly, so libs and headers are copied to "DESTDIR//". \
# DPDK kernel modules are set to install in $DESTDIR/boot/modules, but we move them \
dpdkbuild: don't re-install unchanged shared libs When configuring with --with-shared, you would see all applications getting relinked, even if nothing has changed. This was root caused to DPDK re-installing shared libraries that hadn't been rebuilt. Switching from 'ninja install' to 'meson install --only-changed' fixes this behavior. Note that meson install doesn't support -j, but at this point we are only installing files, not building them - and now we won't even be installing the files again if they haven't changed. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: If0491b2ad6e8564ad0fd8dee39a2e357e1329ea9 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/4465 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
2020-09-29 14:36:20 +00:00
# to DESTDIR/kmod to be consistent with the makefile build. \
# \
# Also use meson install --only-changed instead of ninja install so that the shared \
# libraries don't get reinstalled when they haven't been rebuilt - this avoids all of \
# our applications getting relinked even when nothing has changed.
dpdkbuild: build dpdk with meson+ninja Makefile support in DPDK was deprecated and will be removed soon, so switch to the officially supported way of building DPDK - with meson and ninja. Two new tools. Basically, our Makefiles will invoke meson+ninja for DPDK, no other SPDK components are affected. Apparently DPDK wanted to move away from an octopus-like config system and the ideology behind meson configuration is simple now: build everything by default. Some PMDs can be explicitly disabled with meson command line, but all libraries (both static and shared versions) and test apps are built unconditionally. How long does it take to build minimal DPDK with meson? Too much. On my machine half of the total build time is spent on libraries we don't need at all. (I have some hacks up my sleeve to disable building those libraries - see the subsequent patch.) As for the official way of building a minimal DPDK, there was a patch [1] on dpdk mailing list to introduce more specific configuration, but it was rejected: > We talked about this a few times in the past, and it was actually one > of the design goals to _avoid_ replicating the octopus-like config > system of the makefiles. That's because it makes the test matrix > insanely complicated, not to mention the harm to user friendliness, > among other things. > > If someone doesn't want to use a PMD, they can just avoid installing it > - it's simple enough. > > Sorry, but from me it's a very strong NACK. Let's not follow that direction, hack the DPDK build system instead. As for advantages of meson+ninja over Makefiles? I can't find any. It's another build system that does a lot for you with some functions, magic options, and a built-in dependency system. It seems nice if you know the syntax, but it's another component that you need to learn, debug, and possibly find bugs in (there's a lot of github issues open for meson). I would compare it to CMake. As for changes in this patch: rather that explicitly disabling PMDs we don't need, specify a list of PMDs we do need and disable everything else found in ./dpdk/drivers/*. This way we won't have to disable the new PMDs as they're added to DPDK. Meson configuration also sets RTE_EAL_PMD_PATH #define to a valid directory with built PMD shared libs. When it's set, DPDK dynamically loads all shared libraries inside. The drivers there depend on DPDK shared libs and fail to load in static SPDK builds, so we disable them altogether by unsetting RTE_EAL_PMD_PATH in the meson-generated config file - just like DPDK Makefiles did. EAL checks for RTE_EAL_PMD_PATH being empty and skips loading any external PMDs then. We do it for both static and shared libs. We specify all PMDs at build time for now, so there's just no need to load them dynamically. We have three more hacks in our submodule: * disable building dpdk apps by commenting-out a line in dpdk/meson.build * disable building unnecessary libs (build everything that spdk *may* need) * build isa-l compress pmd with `-L[...] -lisal`. DPDK expects to find libisal with pkg-config. We don't want to prepare a pkg-config file, so comment-out a failing check in another meson.build file and provide isa-l through CFLAGS and LDFLAGS. We also need to make some changes to our test/external_code. First of all, -ldpdk is no more. Meson build generates a pkg-config file with all libs, but we'll switch to it in a separate patch - for now just specify all -lrte_ libs one by one. -Wl,--no-as-needed has to be added to some test cases, otherwise rte_mempool_ring isn't loaded. We don't use any APIs from this library, it only has a static constructor that provides a few callbacks used by rte_mempool_create(). Also, since DPDK now builds both static and shared libraries, we need to add -Wl,-Bstatic to force using static libswhere required. It's only needed for DPDK libs, but we use it for SPDK libs as well since there's no harm. As for performance: $ ./configure --enable-debug --with-crypto --with-reduce $ time make -j40 -C dpdkbuild all with meson: real 0m8.287s user 1m7.983s sys 0m10.548s before, with the old DPDK makefiles: real 0m20.232s user 0m55.921s sys 0m16.491s The subsequent builds are much faster too: $ time make -j40 -C dpdkbuild all meson: real 0m0.876s user 0m0.663s sys 0m0.217s makefiles: real 0m10.150s user 0m11.740s sys 0m6.772s [1] http://inbox.dpdk.org/dev/1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org/ Change-Id: Ic65db563014100bafb12e61ee0530cc2ae64401d Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1440 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2020-03-23 16:55:08 +00:00
$(Q)if [ "$(OS)" = "FreeBSD" ]; then \
env -u MAKEFLAGS DESTDIR=$(SPDK_ROOT_DIR)/dpdk/build ninja -C $(SPDK_ROOT_DIR)/dpdk/build-tmp $(MAKE_NUMJOBS) install > /dev/null && \
mv $(SPDK_ROOT_DIR)/dpdk/build/boot/modules $(SPDK_ROOT_DIR)/dpdk/build/kmod; \
else \
dpdkbuild: don't re-install unchanged shared libs When configuring with --with-shared, you would see all applications getting relinked, even if nothing has changed. This was root caused to DPDK re-installing shared libraries that hadn't been rebuilt. Switching from 'ninja install' to 'meson install --only-changed' fixes this behavior. Note that meson install doesn't support -j, but at this point we are only installing files, not building them - and now we won't even be installing the files again if they haven't changed. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: If0491b2ad6e8564ad0fd8dee39a2e357e1329ea9 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/4465 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com>
2020-09-29 14:36:20 +00:00
env -u MAKEFLAGS meson install -C $(SPDK_ROOT_DIR)/dpdk/build-tmp --only-changed > /dev/null; \
dpdkbuild: build dpdk with meson+ninja Makefile support in DPDK was deprecated and will be removed soon, so switch to the officially supported way of building DPDK - with meson and ninja. Two new tools. Basically, our Makefiles will invoke meson+ninja for DPDK, no other SPDK components are affected. Apparently DPDK wanted to move away from an octopus-like config system and the ideology behind meson configuration is simple now: build everything by default. Some PMDs can be explicitly disabled with meson command line, but all libraries (both static and shared versions) and test apps are built unconditionally. How long does it take to build minimal DPDK with meson? Too much. On my machine half of the total build time is spent on libraries we don't need at all. (I have some hacks up my sleeve to disable building those libraries - see the subsequent patch.) As for the official way of building a minimal DPDK, there was a patch [1] on dpdk mailing list to introduce more specific configuration, but it was rejected: > We talked about this a few times in the past, and it was actually one > of the design goals to _avoid_ replicating the octopus-like config > system of the makefiles. That's because it makes the test matrix > insanely complicated, not to mention the harm to user friendliness, > among other things. > > If someone doesn't want to use a PMD, they can just avoid installing it > - it's simple enough. > > Sorry, but from me it's a very strong NACK. Let's not follow that direction, hack the DPDK build system instead. As for advantages of meson+ninja over Makefiles? I can't find any. It's another build system that does a lot for you with some functions, magic options, and a built-in dependency system. It seems nice if you know the syntax, but it's another component that you need to learn, debug, and possibly find bugs in (there's a lot of github issues open for meson). I would compare it to CMake. As for changes in this patch: rather that explicitly disabling PMDs we don't need, specify a list of PMDs we do need and disable everything else found in ./dpdk/drivers/*. This way we won't have to disable the new PMDs as they're added to DPDK. Meson configuration also sets RTE_EAL_PMD_PATH #define to a valid directory with built PMD shared libs. When it's set, DPDK dynamically loads all shared libraries inside. The drivers there depend on DPDK shared libs and fail to load in static SPDK builds, so we disable them altogether by unsetting RTE_EAL_PMD_PATH in the meson-generated config file - just like DPDK Makefiles did. EAL checks for RTE_EAL_PMD_PATH being empty and skips loading any external PMDs then. We do it for both static and shared libs. We specify all PMDs at build time for now, so there's just no need to load them dynamically. We have three more hacks in our submodule: * disable building dpdk apps by commenting-out a line in dpdk/meson.build * disable building unnecessary libs (build everything that spdk *may* need) * build isa-l compress pmd with `-L[...] -lisal`. DPDK expects to find libisal with pkg-config. We don't want to prepare a pkg-config file, so comment-out a failing check in another meson.build file and provide isa-l through CFLAGS and LDFLAGS. We also need to make some changes to our test/external_code. First of all, -ldpdk is no more. Meson build generates a pkg-config file with all libs, but we'll switch to it in a separate patch - for now just specify all -lrte_ libs one by one. -Wl,--no-as-needed has to be added to some test cases, otherwise rte_mempool_ring isn't loaded. We don't use any APIs from this library, it only has a static constructor that provides a few callbacks used by rte_mempool_create(). Also, since DPDK now builds both static and shared libraries, we need to add -Wl,-Bstatic to force using static libswhere required. It's only needed for DPDK libs, but we use it for SPDK libs as well since there's no harm. As for performance: $ ./configure --enable-debug --with-crypto --with-reduce $ time make -j40 -C dpdkbuild all with meson: real 0m8.287s user 1m7.983s sys 0m10.548s before, with the old DPDK makefiles: real 0m20.232s user 0m55.921s sys 0m16.491s The subsequent builds are much faster too: $ time make -j40 -C dpdkbuild all meson: real 0m0.876s user 0m0.663s sys 0m0.217s makefiles: real 0m10.150s user 0m11.740s sys 0m6.772s [1] http://inbox.dpdk.org/dev/1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org/ Change-Id: Ic65db563014100bafb12e61ee0530cc2ae64401d Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1440 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2020-03-23 16:55:08 +00:00
fi
$(SPDK_ROOT_DIR)/dpdk/build-tmp: $(SPDK_ROOT_DIR)/mk/cc.mk $(SPDK_ROOT_DIR)/include/spdk/config.h
$(Q)rm -rf $(SPDK_ROOT_DIR)/dpdk/build $(SPDK_ROOT_DIR)/dpdk/build-tmp
build/dpdk: disable unused libraries from DPDK submodule Most DPDK libraries are not required for SPDK. Those can be disabled for submodule. Starting with patch https://review.spdk.io/gerrit/c/spdk/dpdk/+/10540 it is possible to not compile a lot of the DPDK libs. This reduces the build time for DPDK submodule. Historically it was done on DPDK submodule side: https://review.spdk.io/gerrit/c/spdk/dpdk/+/2578 Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Change-Id: I4510baf2773fe15835e705bad42cf3ba9f35c418 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/10506 Reviewed-by: Konrad Sztyber <konrad.sztyber@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
2021-12-01 10:12:56 +00:00
$(Q)cd "$(SPDK_ROOT_DIR)/dpdk"; CC="$(SUB_CC)" meson --prefix="$(MESON_PREFIX)" --libdir lib -Dc_args="$(DPDK_CFLAGS)" -Dc_link_args="$(DPDK_LDFLAGS)" $(DPDK_OPTS) -Denable_drivers="$(shell echo $(DPDK_DRIVERS) | sed -E "s/ +/,/g")" -Ddisable_libs="$(shell echo $(DPDK_DISABLED_LIBS) | sed -E "s/ +/,/g")" build-tmp
dpdkbuild: build dpdk with meson+ninja Makefile support in DPDK was deprecated and will be removed soon, so switch to the officially supported way of building DPDK - with meson and ninja. Two new tools. Basically, our Makefiles will invoke meson+ninja for DPDK, no other SPDK components are affected. Apparently DPDK wanted to move away from an octopus-like config system and the ideology behind meson configuration is simple now: build everything by default. Some PMDs can be explicitly disabled with meson command line, but all libraries (both static and shared versions) and test apps are built unconditionally. How long does it take to build minimal DPDK with meson? Too much. On my machine half of the total build time is spent on libraries we don't need at all. (I have some hacks up my sleeve to disable building those libraries - see the subsequent patch.) As for the official way of building a minimal DPDK, there was a patch [1] on dpdk mailing list to introduce more specific configuration, but it was rejected: > We talked about this a few times in the past, and it was actually one > of the design goals to _avoid_ replicating the octopus-like config > system of the makefiles. That's because it makes the test matrix > insanely complicated, not to mention the harm to user friendliness, > among other things. > > If someone doesn't want to use a PMD, they can just avoid installing it > - it's simple enough. > > Sorry, but from me it's a very strong NACK. Let's not follow that direction, hack the DPDK build system instead. As for advantages of meson+ninja over Makefiles? I can't find any. It's another build system that does a lot for you with some functions, magic options, and a built-in dependency system. It seems nice if you know the syntax, but it's another component that you need to learn, debug, and possibly find bugs in (there's a lot of github issues open for meson). I would compare it to CMake. As for changes in this patch: rather that explicitly disabling PMDs we don't need, specify a list of PMDs we do need and disable everything else found in ./dpdk/drivers/*. This way we won't have to disable the new PMDs as they're added to DPDK. Meson configuration also sets RTE_EAL_PMD_PATH #define to a valid directory with built PMD shared libs. When it's set, DPDK dynamically loads all shared libraries inside. The drivers there depend on DPDK shared libs and fail to load in static SPDK builds, so we disable them altogether by unsetting RTE_EAL_PMD_PATH in the meson-generated config file - just like DPDK Makefiles did. EAL checks for RTE_EAL_PMD_PATH being empty and skips loading any external PMDs then. We do it for both static and shared libs. We specify all PMDs at build time for now, so there's just no need to load them dynamically. We have three more hacks in our submodule: * disable building dpdk apps by commenting-out a line in dpdk/meson.build * disable building unnecessary libs (build everything that spdk *may* need) * build isa-l compress pmd with `-L[...] -lisal`. DPDK expects to find libisal with pkg-config. We don't want to prepare a pkg-config file, so comment-out a failing check in another meson.build file and provide isa-l through CFLAGS and LDFLAGS. We also need to make some changes to our test/external_code. First of all, -ldpdk is no more. Meson build generates a pkg-config file with all libs, but we'll switch to it in a separate patch - for now just specify all -lrte_ libs one by one. -Wl,--no-as-needed has to be added to some test cases, otherwise rte_mempool_ring isn't loaded. We don't use any APIs from this library, it only has a static constructor that provides a few callbacks used by rte_mempool_create(). Also, since DPDK now builds both static and shared libraries, we need to add -Wl,-Bstatic to force using static libswhere required. It's only needed for DPDK libs, but we use it for SPDK libs as well since there's no harm. As for performance: $ ./configure --enable-debug --with-crypto --with-reduce $ time make -j40 -C dpdkbuild all with meson: real 0m8.287s user 1m7.983s sys 0m10.548s before, with the old DPDK makefiles: real 0m20.232s user 0m55.921s sys 0m16.491s The subsequent builds are much faster too: $ time make -j40 -C dpdkbuild all meson: real 0m0.876s user 0m0.663s sys 0m0.217s makefiles: real 0m10.150s user 0m11.740s sys 0m6.772s [1] http://inbox.dpdk.org/dev/1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org/ Change-Id: Ic65db563014100bafb12e61ee0530cc2ae64401d Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1440 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2020-03-23 16:55:08 +00:00
$(Q)sed $(SED_INPLACE_FLAG) 's/#define RTE_EAL_PMD_PATH .*/#define RTE_EAL_PMD_PATH ""/g' $(SPDK_ROOT_DIR)/dpdk/build-tmp/rte_build_config.h
$(Q) \
dpdkbuild: remove RTE_HAS_LIBARCHIVE from build config DPDK rte_eal_firmware.c will use libarchive APIs when libarchive is installed on the system. SPDK doesn't currently account for this, so if the user has libarchive installed, DPDK will emit libarchive calls that don't get resolved during link phase for static builds. We've had a similar situation with libbsd for a long time, where we remove the associated #define from the DPDK build config header file before we kick off the DPDK build. So extend that here for the RTE_HAS_LIBARCHIVE #define. It would be nicer to use pkg-config somehow to generate the necessarily libraries to install on the SPDK link line for static builds. But it's not exactly straightforward, so this solution ended up being the simplest by far, extending a mechanism that's worked well with SPDK's dpdkbuild up until this point. Fixes issue #2357. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I79ff4648ee58a3e13f4b873f8acd1b31cca0fc31 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/11385 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Community-CI: Mellanox Build Bot Reviewed-by: Dong Yi <dongx.yi@intel.com> Reviewed-by: Konrad Sztyber <konrad.sztyber@intel.com> Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
2022-01-29 04:40:57 +00:00
# TODO Meson build adds libbsd and/or libarchive dependency when it's available. This means any app will be \
# forced to link with -lbsd and/or -larchive, but only if it's available on the system. The clean way to \
# handle this would be to rely on DPDK's pkg-config file which will contain the -lbsd/-larchive when \
# required. For now just remove the dependencies. DPDK will fallback to its internal functions.
dpdkbuild: build dpdk with meson+ninja Makefile support in DPDK was deprecated and will be removed soon, so switch to the officially supported way of building DPDK - with meson and ninja. Two new tools. Basically, our Makefiles will invoke meson+ninja for DPDK, no other SPDK components are affected. Apparently DPDK wanted to move away from an octopus-like config system and the ideology behind meson configuration is simple now: build everything by default. Some PMDs can be explicitly disabled with meson command line, but all libraries (both static and shared versions) and test apps are built unconditionally. How long does it take to build minimal DPDK with meson? Too much. On my machine half of the total build time is spent on libraries we don't need at all. (I have some hacks up my sleeve to disable building those libraries - see the subsequent patch.) As for the official way of building a minimal DPDK, there was a patch [1] on dpdk mailing list to introduce more specific configuration, but it was rejected: > We talked about this a few times in the past, and it was actually one > of the design goals to _avoid_ replicating the octopus-like config > system of the makefiles. That's because it makes the test matrix > insanely complicated, not to mention the harm to user friendliness, > among other things. > > If someone doesn't want to use a PMD, they can just avoid installing it > - it's simple enough. > > Sorry, but from me it's a very strong NACK. Let's not follow that direction, hack the DPDK build system instead. As for advantages of meson+ninja over Makefiles? I can't find any. It's another build system that does a lot for you with some functions, magic options, and a built-in dependency system. It seems nice if you know the syntax, but it's another component that you need to learn, debug, and possibly find bugs in (there's a lot of github issues open for meson). I would compare it to CMake. As for changes in this patch: rather that explicitly disabling PMDs we don't need, specify a list of PMDs we do need and disable everything else found in ./dpdk/drivers/*. This way we won't have to disable the new PMDs as they're added to DPDK. Meson configuration also sets RTE_EAL_PMD_PATH #define to a valid directory with built PMD shared libs. When it's set, DPDK dynamically loads all shared libraries inside. The drivers there depend on DPDK shared libs and fail to load in static SPDK builds, so we disable them altogether by unsetting RTE_EAL_PMD_PATH in the meson-generated config file - just like DPDK Makefiles did. EAL checks for RTE_EAL_PMD_PATH being empty and skips loading any external PMDs then. We do it for both static and shared libs. We specify all PMDs at build time for now, so there's just no need to load them dynamically. We have three more hacks in our submodule: * disable building dpdk apps by commenting-out a line in dpdk/meson.build * disable building unnecessary libs (build everything that spdk *may* need) * build isa-l compress pmd with `-L[...] -lisal`. DPDK expects to find libisal with pkg-config. We don't want to prepare a pkg-config file, so comment-out a failing check in another meson.build file and provide isa-l through CFLAGS and LDFLAGS. We also need to make some changes to our test/external_code. First of all, -ldpdk is no more. Meson build generates a pkg-config file with all libs, but we'll switch to it in a separate patch - for now just specify all -lrte_ libs one by one. -Wl,--no-as-needed has to be added to some test cases, otherwise rte_mempool_ring isn't loaded. We don't use any APIs from this library, it only has a static constructor that provides a few callbacks used by rte_mempool_create(). Also, since DPDK now builds both static and shared libraries, we need to add -Wl,-Bstatic to force using static libswhere required. It's only needed for DPDK libs, but we use it for SPDK libs as well since there's no harm. As for performance: $ ./configure --enable-debug --with-crypto --with-reduce $ time make -j40 -C dpdkbuild all with meson: real 0m8.287s user 1m7.983s sys 0m10.548s before, with the old DPDK makefiles: real 0m20.232s user 0m55.921s sys 0m16.491s The subsequent builds are much faster too: $ time make -j40 -C dpdkbuild all meson: real 0m0.876s user 0m0.663s sys 0m0.217s makefiles: real 0m10.150s user 0m11.740s sys 0m6.772s [1] http://inbox.dpdk.org/dev/1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org/ Change-Id: Ic65db563014100bafb12e61ee0530cc2ae64401d Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1440 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2020-03-23 16:55:08 +00:00
$(Q)sed $(SED_INPLACE_FLAG) 's/#define RTE_USE_LIBBSD .*//g' $(SPDK_ROOT_DIR)/dpdk/build-tmp/rte_build_config.h
dpdkbuild: remove RTE_HAS_LIBARCHIVE from build config DPDK rte_eal_firmware.c will use libarchive APIs when libarchive is installed on the system. SPDK doesn't currently account for this, so if the user has libarchive installed, DPDK will emit libarchive calls that don't get resolved during link phase for static builds. We've had a similar situation with libbsd for a long time, where we remove the associated #define from the DPDK build config header file before we kick off the DPDK build. So extend that here for the RTE_HAS_LIBARCHIVE #define. It would be nicer to use pkg-config somehow to generate the necessarily libraries to install on the SPDK link line for static builds. But it's not exactly straightforward, so this solution ended up being the simplest by far, extending a mechanism that's worked well with SPDK's dpdkbuild up until this point. Fixes issue #2357. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I79ff4648ee58a3e13f4b873f8acd1b31cca0fc31 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/11385 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Community-CI: Mellanox Build Bot Reviewed-by: Dong Yi <dongx.yi@intel.com> Reviewed-by: Konrad Sztyber <konrad.sztyber@intel.com> Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
2022-01-29 04:40:57 +00:00
$(Q)sed $(SED_INPLACE_FLAG) 's/#define RTE_HAS_LIBARCHIVE .*//g' $(SPDK_ROOT_DIR)/dpdk/build-tmp/rte_build_config.h
build: add intel-ipsec-mb submodule This is a dependency of the DPDK crypto framework. The submodule is currently set to our SPDK fork of the ipsec library which is based off of the library v0.48 tag, as required by DPDK plus one minor Makefile change on the 'spdk' branch of the fork. Also added is a configure option '--with-crypto' and the associated conditionals for building DPDK with or without the library dependency. The crypto vbdev patch will use this same configure option to determine DPDK opts as well as whether the crypto vbdev should be built or not. Change-Id: Ib1cfd15b63b29acf3c2f7345d0d7edfd94716620 Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com> Signed-off-by: paul luse <paul.e.luse@intel.com> Reviewed-on: https://review.gerrithub.io/404983 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com> Reviewed-by: Changpeng Liu <changpeng.liu@intel.com>
2018-03-22 23:24:14 +00:00
build: add dpdk as a submodule This will allow a git clone to default to an SPDK-specific version of the DPDK repository. Users can still override to use a separate DPDK repository/installation with the --with-dpdk configure script options. While here, remove gzip option for the git-archive operations in autopackage.sh. We need to add a git-archive for the DPDK submodule if we are using it, and compressing at -9 adds a lot of unnecessary time. Since we are not archiving these packages, there is no need to compress them. Also explicitly disable coverage and ubsan for the autopackage build, since this build is only to test compilation and is not actually used for any test execution. Signed-off-by: Jim Harris <james.r.harris@intel.com> Change-Id: I3cf8a2ed984003a175cdece6542636ede8cb2479
2017-05-08 22:07:13 +00:00
clean:
dpdkbuild: build dpdk with meson+ninja Makefile support in DPDK was deprecated and will be removed soon, so switch to the officially supported way of building DPDK - with meson and ninja. Two new tools. Basically, our Makefiles will invoke meson+ninja for DPDK, no other SPDK components are affected. Apparently DPDK wanted to move away from an octopus-like config system and the ideology behind meson configuration is simple now: build everything by default. Some PMDs can be explicitly disabled with meson command line, but all libraries (both static and shared versions) and test apps are built unconditionally. How long does it take to build minimal DPDK with meson? Too much. On my machine half of the total build time is spent on libraries we don't need at all. (I have some hacks up my sleeve to disable building those libraries - see the subsequent patch.) As for the official way of building a minimal DPDK, there was a patch [1] on dpdk mailing list to introduce more specific configuration, but it was rejected: > We talked about this a few times in the past, and it was actually one > of the design goals to _avoid_ replicating the octopus-like config > system of the makefiles. That's because it makes the test matrix > insanely complicated, not to mention the harm to user friendliness, > among other things. > > If someone doesn't want to use a PMD, they can just avoid installing it > - it's simple enough. > > Sorry, but from me it's a very strong NACK. Let's not follow that direction, hack the DPDK build system instead. As for advantages of meson+ninja over Makefiles? I can't find any. It's another build system that does a lot for you with some functions, magic options, and a built-in dependency system. It seems nice if you know the syntax, but it's another component that you need to learn, debug, and possibly find bugs in (there's a lot of github issues open for meson). I would compare it to CMake. As for changes in this patch: rather that explicitly disabling PMDs we don't need, specify a list of PMDs we do need and disable everything else found in ./dpdk/drivers/*. This way we won't have to disable the new PMDs as they're added to DPDK. Meson configuration also sets RTE_EAL_PMD_PATH #define to a valid directory with built PMD shared libs. When it's set, DPDK dynamically loads all shared libraries inside. The drivers there depend on DPDK shared libs and fail to load in static SPDK builds, so we disable them altogether by unsetting RTE_EAL_PMD_PATH in the meson-generated config file - just like DPDK Makefiles did. EAL checks for RTE_EAL_PMD_PATH being empty and skips loading any external PMDs then. We do it for both static and shared libs. We specify all PMDs at build time for now, so there's just no need to load them dynamically. We have three more hacks in our submodule: * disable building dpdk apps by commenting-out a line in dpdk/meson.build * disable building unnecessary libs (build everything that spdk *may* need) * build isa-l compress pmd with `-L[...] -lisal`. DPDK expects to find libisal with pkg-config. We don't want to prepare a pkg-config file, so comment-out a failing check in another meson.build file and provide isa-l through CFLAGS and LDFLAGS. We also need to make some changes to our test/external_code. First of all, -ldpdk is no more. Meson build generates a pkg-config file with all libs, but we'll switch to it in a separate patch - for now just specify all -lrte_ libs one by one. -Wl,--no-as-needed has to be added to some test cases, otherwise rte_mempool_ring isn't loaded. We don't use any APIs from this library, it only has a static constructor that provides a few callbacks used by rte_mempool_create(). Also, since DPDK now builds both static and shared libraries, we need to add -Wl,-Bstatic to force using static libswhere required. It's only needed for DPDK libs, but we use it for SPDK libs as well since there's no harm. As for performance: $ ./configure --enable-debug --with-crypto --with-reduce $ time make -j40 -C dpdkbuild all with meson: real 0m8.287s user 1m7.983s sys 0m10.548s before, with the old DPDK makefiles: real 0m20.232s user 0m55.921s sys 0m16.491s The subsequent builds are much faster too: $ time make -j40 -C dpdkbuild all meson: real 0m0.876s user 0m0.663s sys 0m0.217s makefiles: real 0m10.150s user 0m11.740s sys 0m6.772s [1] http://inbox.dpdk.org/dev/1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org/ Change-Id: Ic65db563014100bafb12e61ee0530cc2ae64401d Signed-off-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com> Signed-off-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/1440 Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2020-03-23 16:55:08 +00:00
$(Q)rm -rf $(SPDK_ROOT_DIR)/dpdk/build $(SPDK_ROOT_DIR)/dpdk/build-tmp
build: add 'make install' rule For now, this only installs libraries and headers; we will need to consider which binaries should be installed and what they should be named before we add them to the install rule. Change-Id: I78dc8631f793d0df88cd884b0ac66406df9e4427 Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com> Reviewed-on: https://review.gerrithub.io/387637 Tested-by: SPDK Automated Test System <sys_sgsw@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2017-11-15 17:36:36 +00:00
build: Don't compile DPDK when doing make install Signed-off-by: Ben Walker <benjamin.walker@intel.com> Change-Id: I146bc479ddb2c84760a21e4f5a009b9ec8e53700 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/2644 Community-CI: Mellanox Build Bot Community-CI: Broadcom CI Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Paul Luse <paul.e.luse@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Darek Stojaczyk <dariusz.stojaczyk@intel.com>
2020-05-27 17:21:30 +00:00
install:
@:
Makefile: Add possibility to uninstall spdk. Add uninstall target to makefiles to be able to perform reverse of install target. Fixes #464 This patch adds 'uninstall' target to makefile. 'make uninstall' will remove spdk_tgt app, headers, libraries and shared libraries from system directories defined by $DESTDIR. Additionaly, if there will be any empty directories left after this operation, they will be removed as well. Signed-off-by: Piotr Pelplinski <piotr.pelplinski@intel.com> Change-Id: I7b07fb4b81081d3914ff09165991fbe3a26b9067 Signed-off-by: Pawel Kaminski <pawelx.kaminski@intel.com> Reviewed-on: https://review.gerrithub.io/c/spdk/spdk/+/431471 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com>
2019-01-02 09:28:02 +00:00
uninstall:
@:
Reference in New Issue Copy Permalink