This patch moves the kernel modules code from EAL to a common place.
- Separate the kernel module code from user space code.
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Tested-by: Bruce Richardson <bruce.richardson@intel.com>
Added support for detecting march and mcpu by reading midr_el1 register.
The implementer, primary part number values read can be used to figure
out the underlying arm cpu.
Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com>
Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
This patch enables the test/test app to be built. It also adds
the test binary to be a meson-test, which allows the meson test
infrastructure to be used to run tests.
Tests are listed using the same test binary, however each test
sets a different DPDK_TEST environment variable. The string contents
of this DPDK_TEST env var is entered in the command line interface.
As such, the familiar test names such as "ring_perf_autotest" etc
are valid tests to run using this meson test infrastructure.
Note that the tests are run serially, given that we cannot run
multiple primary processes at a time. As each test must initialize
EAL this takes some time depending on the number of hugepages.
In future, we could improve this to run multiple tests from one
EAL init, but it is out of scope for this patchset.
Finally, an option to build the tests is added to the meson build
options. When disabled, the unit test code in test/test is not
compiled. The default is set to 'true'. To disable, run:
$ meson configure -Dtests=false
Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Any flags added to the project args are automatically added to all builds,
both native and cross-compiled. This is not what we want for the -march
flag as a valid -march for the cross-compile is not valid for pmdinfogen
which is a native-build tool.
Instead we store the march flag as a variable, and add it to the default
cflags for all libs, drivers, examples, etc. This will allow pmdinfogen to
compile successfully in a cross-compilation environment.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
With the introduction of bus drivers, we now have a situation where
driver libraries will start to depend upon each other. Because of this,
the driver libs need to be discoverable by the dynamic loader.
There are three options to fix this:
1. Force the user to put the $libdir/dpdk/drivers folder into their
library path.
2. Move all libraries from drivers sub-directory to $libdir.
3. Symlink all libraries from the subfolder to the main library dir.
Option 1 is not great for usability or distro packaging, and option 2
means that we can't have EAL load all drivers from a known path
automatically (as it would error out on non-PMD libs), so option 3 was
chosen as the best fix. The only downside is that on a "ninja uninstall"
the symlinks are not removed, as they are unknown to meson/ninja.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Now that we always build both static and shared libraries, the default
library type only applies to apps and examples. To avoid issues with
paths when doing actual development with DPDK, change the default app
build to static. This makes sure that testpmd, and any examples built as
part of a development build, are runnable without being installed.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
This patch changes the build process to group all .o files for a driver or
library into a static archive first, and then link the .o files together
into a shared library. This eliminates the need for separate static or
shared object builds when packaging, for instance.
The "default_library" configuration option now only affects the apps and
examples, which are either linked against the static or shared library
versions depending on the value of the option.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Add support for having selected example apps built as part of a meson,
ninja build. By default none are built, and those to be built should be
named directly in the -Dexamples='' meson configuration argument.
This is useful for developers working on a feature who want to use a
suitable example, or examples, to test that feature, as they can compile
everything up in one go, and run the example without having to do a ninja
install first.
This commit adds examples which don't consist of multiple apps in
subdirectories to the meson build, so they can be built by default by
passing -Dexamples parameter to meson.
Not included are the following examples:
* ethtool
* multi-process
* netmap_compat
* performance-thread
* quota_watermark
* server_node_efd
* vm_power_manager
To test the apps added here, use the following command, merged to one line,
to add them to your meson build (command to be run inside the build
directory):
meson configure -Dexamples=bbdev_app,bond,cmdline,distributor,\
eventdev_pipeline_sw_pmd, exception_path,helloworld,\
ip_fragmentation,ip_pipeline,ip_reassembly, ipsec-secgw,\
ipv4_multicast,kni,l2fwd-cat,l2fwd-crypto,l2fwd-jobstats,\
l2fwd-keepalive,l2fwd,l3fwd-acl,l3fwd-power,l3fwd-vf,l3fwd,\
link_status_interrupt,load_balancer,packet_ordering,ptpclient,\
qos_meter,qos_sched,rxtx_callbacks,skeleton,tep_termination,\
timer,vhost,vhost_scsi,vmdq,vmdq_dcb
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Luca Boccassi <bluca@debian.org>
To comply with the "hier" standard [Ref: man 7 hier], the driver .so files
should not be placed in $datadir. Therefore we install them in a
sub-directory of $libdir instead.
Fixes: a25a650be5 ("build: add infrastructure for meson and ninja builds")
Reported-by: Timothy Redaelli <tredaelli@redhat.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
A subset of the dpdk headers are arch-dependent, but have common names
and thus cause a clash in a multiarch installation.
For example, rte_config.h is different for each target.
Add a "include_subdir_arch" option to allow a user to specify a
subdirectory for arch independent headers to fix multiarch support.
Signed-off-by: Luca Boccassi <bluca@debian.org>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
In Debian and Ubuntu we have been shipping a pkgconfig file for DPDK
for more than a year now, and the filename is libdpdk.pc.
A few downstream projects, like OVS and Collectd, have adopted the
use of libdpdk.pc in their build systems as well.
In order to maintain backward compatibility, rename the file from
DPDK.pc to libdpdk.pc.
Signed-off-by: Luca Boccassi <bluca@debian.org>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Have the "usertools" scripts installed when doing a DPDK install using
ninja. They will be copies to $prefix/bin, generally /usr/local/bin,
alongside testpmd.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Harry van Haaren <harry.van.haaren@intel.com>
Acked-by: Keith Wiles <keith.wiles@intel.com>
Acked-by: Luca Boccassi <luca.boccassi@gmail.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Harry van Haaren <harry.van.haaren@intel.com>
Acked-by: Keith Wiles <keith.wiles@intel.com>
Acked-by: Luca Boccassi <luca.boccassi@gmail.com>
Add in the top-level drivers meson.build file to start adding in building
of PMDs. Since all PMDs are built in pretty much the same way, the logic
for building each PMD, including extracting the pmdinfo, is included in the
top level build file. This means that each individual driver class only
needs to specify its default dependencies and a few naming conventions, and
each driver only needs to specify it's source files, headers, etc.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Harry van Haaren <harry.van.haaren@intel.com>
Acked-by: Keith Wiles <keith.wiles@intel.com>
Acked-by: Luca Boccassi <luca.boccassi@gmail.com>
Add the buildtools folder, and more specifically the pmdinfogen binary to
the meson and ninja build. This will be needed for building the PMDs in the
driver folder later, as the pmd info output from the tool needs to be
included in those libs.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Harry van Haaren <harry.van.haaren@intel.com>
Acked-by: Keith Wiles <keith.wiles@intel.com>
Acked-by: Luca Boccassi <luca.boccassi@gmail.com>
Support building the EAL with meson and ninja. This involves a number of
different meson.build files for iterating through all the different
subdirectories in the EAL. The library itself will be compiled on build but
the header files are only copied from their initial location once "ninja
install" is run. Instead, we use meson dependency tracking to ensure that
other libraries which use the EAL headers can find them in their original
locations.
Note: this does not include building kernel modules on either BSD or Linux
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Harry van Haaren <harry.van.haaren@intel.com>
Acked-by: Keith Wiles <keith.wiles@intel.com>
Acked-by: Luca Boccassi <luca.boccassi@gmail.com>
To build with meson and ninja, we need some initial infrastructure in
place. The build files for meson always need to be called "meson.build",
and options get placed in meson_options.txt
This commit adds a top-level meson.build file, which sets up the global
variables for tracking drivers, libraries, etc., and then includes other
build files, before finishing by writing the global build configuration
header file and a DPDK pkgconfig file at the end, using some of those same
globals.
From the top level build file, the only include file thus far is for the
config folder, which does some other setup of global configuration
parameters, including pulling in architecture specific parameters from an
architectural subdirectory. A number of configuration build options are
provided for the project to tune a number of global variables which will be
used later e.g. max numa nodes, max cores, etc. These settings all make
their way to the global build config header "rte_build_config.h". There is
also a file "rte_config.h", which includes "rte_build_config.h", and this
file is meant to hold other build-time values which are present in our
current static build configuration but are not normally meant for
user-configuration. Ideally, over time, the values placed here should be
moved to the individual libraries or drivers which want those values.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Harry van Haaren <harry.van.haaren@intel.com>
Acked-by: Keith Wiles <keith.wiles@intel.com>
Acked-by: Luca Boccassi <luca.boccassi@gmail.com>
