The "default" part in configuration filenames is misleading.
Rename this as "native", as this is the RTE_MACHINE that is set in these files.
This should make it clearer for people who build DPDK on a system then run it on
another one.
Signed-off-by: David Marchand <david.marchand@6wind.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Convert the vmxnet3 pmd driver to use the PMD_REGISTER_DRIVER macro.
This means that the test applications now have no reference to the vmxnet3 library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Convert the virtio pmd driver to use the PMD_REGISTER_DRIVER macro.
This means that the test applications now have no reference to the virtio library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Convert the ixgbevf pmd driver to use the PMD_REGISTER_DRIVER macro.
This means that the test applications now have no reference to the ixgbevf library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Convert the e1000 pmd driver to use the PMD_REGISTER_DRIVER macro.
This means that the test applications now have no reference to the e1000 library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Convert the xenvirt driver to use the PMD_REGISTER_DRIVER macro.
This means that the test applications now have no reference to the xenvirt library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically.
A few notes:
xenvirt was unbuildable as of commit 4c39baf297d10c217e7d3e7370f26a1fede58308..
That commit neglected to include the rte_vdev.h header, so several structs were
left undefined. This patch includes a fix for that as well.
Also, The linkage for xenvirt is broken in much the same way pmd_ring was, in
that the xenvirt pmd has a function that is called directly from applications
(the example being the testpmd application). The function is
rte_mempool_gntalloc_create, and should clearly be moved into the rte_mempool
library, with the supporting code in the function implementation moved to a new
xenvirt library separate from the pmd. This is a large undertaking that
detracts from the purpose of this series however, and so for now, I'm leaving
the linkage to the application in place, and will address this issue in a later
series
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Convert the ring driver to use the PMD_REGISTER_DRIVER macro and fix up the
Makefile so that its linkage is only done if we are building static libraries.
This means that the test applications now have no reference to the ring library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically.
Note that the ring driver was also written in such a way that it violated some
general layering principles, several functions were contained in the pmd which
were being called by example from the test application in the app/test
directory. Specifically it was calling eth_ring_pair_attach,
eth_ring_pair_create and rte_eth_ring_devinit, which should only be called
internally to the dpdk core library. To correct this I've removed those
functions, and instead allowed them to be called indirectly at initalization
time using the vdev command line argument key nodeaction=<name>:<node>:<action>
where action is one of ATTACH or CREATE. I've tested out the functionality of
the command line with the testpmd utility, with success, and have removed the
called functions from the test utility. This will affect how the test utility
is invoked (the -d and --vdev option will need to be specified on the command
line now), but honestly, given the way it was coded, I think the testing of the
ring pmd was not the best example of how to code with dpdk to begin with. I
have also left the two layer violating functions in place, so as not to break
existing applications, but added deprecation warnings to them so that apps can
migrate off them.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Convert the pcap driver to use the PMD_REGISTER_DRIVER macro and fix up the
Makefile so that its linkage is only done if we are building static libraries.
This means that the test applications now have no reference to the pcap library
when building DSO's and must specify its use on the command line with the -d
option. Static linking will still initalize the driver automatically.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
It is now possible to build all projects from the examples/ directory
using one command from root directory.
Some illustration of what is possible:
- build examples in the DPDK tree for one target
# install the x86_64-default-linuxapp-gcc in
# ${RTE_SDK}/x86_64-default-linuxapp-gcc directory
user@droids:~/dpdk.org$ make install T=x86_64-default-linuxapp-gcc
# build examples for this new installation in
# ${RTE_SDK}/examples directory
user@droids:~/dpdk.org$ make examples T=x86_64-default-linuxapp-gcc
- build examples outside DPDK tree for several targets
# install all targets matching x86_64-*-linuxapp-gcc in
# ${RTE_SDK}/x86_64-*-linuxapp-gcc directories
user@droids:~/dpdk.org$ make install T=x86_64-*-linuxapp-gcc
# build examples for these installations in /tmp/foobar
user@droids:~/dpdk.org$ make examples T=x86_64-*-linuxapp-gcc O=/tmp/foobar
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
This makefile can be included by a project that needs to build several
applications or libraries that are located in different directories.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Trying to install headers for an external library using DPDK exported makefile
rte.extshared.mk results in following error :
$ cd dpdk
$ make install DESTDIR=/home/marchand/myapp/staging/plop T=x86_64-default-linuxapp-gcc
$ cd ~/myapp
$ make RTE_SDK=/home/marchand/myapp/staging/plop RTE_TARGET=x86_64-default-linuxapp-gcc
CC plop.o
LD plop.so
SYMLINK-FILE include/plop.h
/bin/sh:
/home/marchand/myapp/staging/plop/scripts/relpath.sh: No such file or directory
ln: `/home/marchand/myapp/build/include' and `./include' are the same file
make[1]: *** [/home/marchand/myapp/build/include/plop.h] Error 1
make: *** [all] Error 2
This comes from the fact that DPDK only installs its mk/ directory while some
makefiles require the scripts/ directory content as well.
So install missing files from scripts/.
Signed-off-by: David Marchand <david.marchand@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Start development cycle for version 1.7.0.
This new development workflow introduces a new versioning scheme.
Instead of having releases r0, r1, r2, etc, there will be release
candidates. Last number has special meanings:
< 16 numbers are reserved for release candidates (RTE_VER_SUFFIX is -rc)
16 is reserved for the release (RTE_VER_SUFFIX must be unset)
> 16 numbers can be used locally (RTE_VER_SUFFIX must be set)
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
The config templates can be seen with "make showconfigs", "make config" or
"make help". It's easier to read if it's sorted.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
If some DPDK libraries are installed on the system, the linker was trying
to use them before searching in -L path.
The obscure reason is that we were prefixing -L with -Wl, to pass it
directly to the linker.
But -L is also a gcc option. And allowing gcc to process this option fixes
the issue.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
This allows to use V=1 to be more verbose to debug the build process
of a bsd kernel module.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
The shared libraries built with the current makefile set produce static
libraries rather than actual shared objects. This is due to several missing
options that are required to correctly build shared objects using ld, as well as
a mis-specified -share option (which should be -shared). Switching to the use of
CC rather than LD and fixing the -shared option corrects these problems and
builds the DSOs correctly.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Pass CROSS_COMPILE to the kernel build system when compiling kernel
modules. Although we export CC etc. the top level kernel Makefile will
override the environment. As a result it will end up using wrong tools
if cross-compilation is desired but CROSS_COMPILE is not set.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nsn.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
To fully support dpdk extensions (loading of .so), all symbols provided
by dpdk libraries must be available in the binaries: before this patch,
unused functions/variables from dpdk static libraries could be stripped
by the linker because they are not used. These symbols can be used by a
dpdk extension that is loaded at runtime with the -d option.
Adding --whole-archive when generating a binary solves this issue.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
If .config file is changed and .depdirs was built before,
it must be updated.
It is now done silently (-s) in checkconfig rule.
Now .depdirs is not redone if .config is older.
It has been tested by enabling PMD_PCAP after a default build.
KVARGS dependency should appear in .depdirs.
There is also a typo fix for PHONY rule.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
In order to distinguish clearly this implementation from the extension
vmxnet3-usermap, it is renamed to reflect its usage of uio framework.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Thomas Graf <tgraf@redhat.com>
In order to distinguish clearly this implementation from the extension
virtio-net-pmd, it is renamed to reflect its usage of uio framework.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Chris Wright <chrisw@redhat.com>
This reverts commits
a0cdfcf9 (use pcap-config to guess compilation flags),
ef5b2363 (fix build with empty LIBPCAP_CFLAGS) and
60191b89 (fix build when pcap_sendpacket is unavailable).
These patches are creating more problems than solving the initial one
(which was a build error with too old pcap libraries).
Since old pcap libraries are not that common, just revert them.
Reported-by: Meir Tseitlin <mirots@gmail.com>
Reported-by: Mats Liljegren <mats.liljegren@enea.com>
Signed-off-by: David Marchand <david.marchand@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
In rte.sdkbuild.mk with CONFIG_RTE_LIBRTE_PMD_PCAP=y,
we error-exit if LIBPCAP_CFLAGS is empty.
On some distros (e.g., Centos 6.4), it is normal for "pcap-config --cflags"
to output only a newline, because pcap header files reside in /usr/include/.
Solution is to remove the line that checks whether LIBPCAP_CFLAGS is empty.
Signed-off-by: Robert Sanford <rsanford@prolexic.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Use pcap-config to populate CFLAGS and LDFLAGS.
LIBPCAP_CFLAGS and LIBPCAP_LDFLAGS can be used to override this (useful when
cross-compiling).
Signed-off-by: David Marchand <david.marchand@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Add an option to specify libraries to be loaded before probing the PCI.
For instance, testpmd -d librte_pmd_xxx.so can be used to enable xxx driver
support on testpmd without any recompilation of testpmd.
Plugins are loaded before creating threads because we want the threads to
inherit any property that could be set while loading a plugin, such as iopl().
Signed-off-by: Damien Millescamps <damien.millescamps@6wind.com>
Signed-off-by: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com>
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Before recompiling a file, rte.compile-pre.mk checks whether the command
line is different from the previous one.
This is done by storing for each object file the entire command line in a
kind of dependency file with a .cmd extension (see obj2cmd). If that file
exists, the line is retrieved first and compared against $(C_TO_O_STR).
The object file gets recompiled if the file doesn't exist or if the line
is different.
The problem is that sometimes, files are recompiled for no apparent reason.
The check doesn't work properly when a command line contains double-quoted
strings such as -DFOO='"bar"' because the shell interprets and strips them.
This is fixed by protecting C_TO_O_CMD with simple quotes, knowing that
such quotes are already escaped in C_TO_O_STR.
Moreover, because simple quotes are escaped in C_TO_O_STR, the retrieved
command should be compared against C_TO_O instead.
Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
The GCC prefix -Wl was ignored because the command line value has higher priority.
It ended in impossibilty for GCC to pass parameters to LD.
The prefixed value must override the command line one.
Signed-off-by: Julien Courtat <julien.courtat@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Add mk/rte.shared.mk and mk/rte.extshared.mk in framework to
allow shared libraries compilation through framework
Signed-off-by: Didier Pallard <didier.pallard@6wind.com>
Acked-by: Ivan Boule <ivan.boule@6wind.com>
This will install the binary sdk (bin + modules + libs + headers + mk)
in the specified directory.
This directory can be used as RTE_SDK by external applications.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
This allows the user to prepare a configuration with make config
before using make install.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
This variable $(O) can be used to specify a build directory
when doing an "install" procedure. The default is ".", which
means that targets will be built in the source dpdk.
This option is useful to compile outside of the source tree that may be
read-only.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
The goal of this rule is to show which rules/options are available from a
"make" command.
Let's start by printing short doc about SDK building.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Reviewed-by: Olivier Matz <olivier.matz@6wind.com>
Allow to list configs in config/ directory with a simple make rule.
The rule showconfigs is reused in config error.
In the same time, "echo -n" is replaced by the more portable "printf".
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Reviewed-by: Olivier Matz <olivier.matz@6wind.com>
The parameter PROJECT_NUMBER is used in the HTML header
via the template variable $projectnumber.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Vincent Jardin <vincent.jardin@6wind.com>
The version string is extracted from rte_version.h.
RTE_VER_* macros are concatenated and separators " . . r " are inserted.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Vincent Jardin <vincent.jardin@6wind.com>
- add index page
- add doxygen configuration for API
- add doxygen CSS customization applied by a script
- HTML generation via make rules
The configuration is splitted in a static file and a make rule in order to
dynamically configure output format and path.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: David Marchand <david.marchand@6wind.com>
It seems that doc/ has been removed so these rules are useless.
This clean-up is preliminary to generate some doc.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
rte.sdkroot.mk is mainly calling other makefiles.
These redirecting rules can be factorized by called makefile.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
Poll Mode Driver for Paravirtual VMXNET3 NIC.
As a PMD, the VMXNET3 driver provides the packet reception and transmission
callbacks, vmxnet3_recv_pkts and vmxnet3_xmit_pkts. It does not support
scattered packet reception as part of vmxnet3_recv_pkts and
vmxnet3_xmit_pkts. Also, it does not support scattered packet reception as part of
the device operations supported.
The VMXNET3 PMD handles all the packet buffer memory allocation and resides in
guest address space and it is solely responsible to free that memory when not needed.
The packet buffers and features to be supported are made available to hypervisor via
VMXNET3 PCI configuration space BARs. During RX/TX, the packet buffers are
exchanged by their GPAs, and the hypervisor loads the buffers with packets in the RX
case and sends packets to vSwitch in the TX case.
The VMXNET3 PMD is compiled with vmxnet3 device headers. The interface is similar
to that of the other PMDs available in the Intel(R) DPDK API. The driver pre-allocates the
packet buffers and loads the command ring descriptors in advance. The hypervisor fills
those packet buffers on packet arrival and write completion ring descriptors, which are
eventually pulled by the PMD. After reception, the Intel(R) DPDK application frees the
descriptors and loads new packet buffers for the coming packets. The interrupts are
disabled and there is no notification required. This keeps performance up on the RX
side, even though the device provides a notification feature.
In the transmit routine, the Intel(R) DPDK application fills packet buffer pointers in the
descriptors of the command ring and notifies the hypervisor. In response the hypervisor
takes packets and passes them to the vSwitch. It writes into the completion descriptors
ring. The rings are read by the PMD in the next transmit routine call and the buffers
and descriptors are freed from memory.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
This provides a para-virtualization packet switching solution, based on the
Xen hypervisor’s Grant Table, which provides simple and fast packet
switching capability between guest domains and host domain based on
MAC address or VLAN tag.
This solution is comprised of two components; a Poll Mode Driver (PMD)
as the front end in the guest domain and a switching back end in the
host domain. XenStore is used to exchange configure information
between the PMD front end and switching back end,
including grant reference IDs for shared Virtio RX/TX rings, MAC
address, device state, and so on.
The front end PMD can be found in the Intel DPDK directory lib/
librte_pmd_xenvirt and back end example in examples/vhost_xen.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
These library changes provide a new Intel DPDK feature for communicating
with virtual machines using QEMU's IVSHMEM mechanism.
The feature works by providing a command line for QEMU to map several hugepages
into a single IVSHMEM device. For the guest to know what is inside any given IVSHMEM
device (and to distinguish between Intel(R) DPDK and non-Intel(R) DPDK IVSHMEM
devices), a metadata file is also mapped into the IVSHMEM segment. No work needs to
be done by the guest application to map IVSHMEM devices into memory; they are
automatically recognized by the Intel(R) DPDK Environment Abstraction Layer (EAL).
Changes in this patch:
* Changes to EAL to allow mapping of all hugepages in a memseg into a single file
* Changes to EAL to allow ivshmem devices to be transparently mapped in
the process running on the guest.
* New ivshmem library to create and manage metadata exported to guest VM's
* New ivshmem compilation targets
* Mempool and ring changes to allow export of structures to a VM and allow
a VM to attach to those structures.
* New autotests to unit tests this functionality.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Add support for haswell based systems.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: David Marchand <david.marchand@6wind.com>
For cases where the compilation microarchitecture is explicitly given, we
extract the cpu-flags to use from the compiler rather than hard-coding. This
means that we will only ever use instruction sets supported by the compiler,
rather than having a case where the uarch and the Intel DPDK both support a
given instruction-set, but the compiler does not.
In the case where 'native' uarch support is requested, the same mechanism is
also used to detect the instruction-sets supported
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: David Marchand <david.marchand@6wind.com>
- Configuration for combined and shared library was only in the template
defconfig_x86_64-default-linuxapp-gcc.
- CONFIG_RTE_LIBNAME was in the wrong section
- RTE_LIBNAME had no quote in "C context" (include/rte_config.h)
- and then CONFIG_RTE_LIBNAME quotes were not properly removed in "make context"
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
Changes to allow compilation and use on FreeBSD. Includes:
* contigmem and nic_uio driver for FreeBSD
* new EAL instance
* new "bsdapp" compilation target
* various compilation fixes due to differences between linux and freebsd
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
