Make versions before 4.2 did not have support for the .SHELLSTATUS
variable, so use another method to detect shell success.
Fixes: 22119c4591a0 ("examples: use pkg-config in makefiles")
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
For testing of DPDK, we want to override the prefix given by the
pkg-config file, so that we can get correct paths for DPDK installed
in an unusual location.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
The "make clean" command had a number of issues:
- the "--ignore-fail-on-non-empty" flag is not present on BSD
- the call to remove the build folder would fail if there was no build
folder present.
These are fixed by only removing the build folder if it exists, and by
using -p flag to rmdir in place of --ignore-fail-on-non-empty
Fixes: 22119c4591a0 ("examples: use pkg-config in makefiles")
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Most examples have in their makefiles a default RTE_TARGET directory to be
used in case RTE_TARGET is not set. Rather than just using a hard-coded
default, we can instead detect what the build directory is relative to
RTE_SDK directory.
This fixes a potential issue for anyone who continues to build using
"make install T=x86_64-native-linuxapp-gcc" and skips setting RTE_TARGET
explicitly, instead relying on the fact that they were building in a
directory which corresponded to the example default path - which was
changed to "x86_64-native-linux-gcc" by commit 218c4e68c1d9 ("mk: use
linux and freebsd in config names").
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Rather than using linuxapp and bsdapp everywhere, we can change things to
use the, more readable, terms "linux" and "freebsd" in our build configs.
Rather than renaming the configs we can just duplicate the existing ones
with the new names using symlinks, and use the new names exclusively
internally. ["make showconfigs" also only shows the new names to keep the
list short] The result is that backward compatibility is kept fully but any
new builds or development can be done using the newer names, i.e. both
"make config T=x86_64-native-linuxapp-gcc" and "T=x86_64-native-linux-gcc"
work.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Rename the macro to make things shorter and more comprehensible. For
both meson and make builds, keep the old macro around for backward
compatibility.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Some Makefiles are using CONFIG_RTE_EXEC_ENV and others
are using CONFIG_RTE_EXEC_ENV_LINUXAPP.
Use the latter one for consistency.
We could remove CONFIG_RTE_EXEC_ENV later if considered useless.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
IP_Pipeline app is not supported in FreeBSD environment. Therefore,
skip it while building the sample apps on FreeBSD.
Fixes: 4bbf8e30aa5e ("examples/ip_pipeline: add CLI interface")
Fixes: 2f74ae28e23f ("examples/ip_pipeline: add tap object")
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Add threads data structure and initialisation functions to run
the pipeline.
Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Add tap object implementation to the application
Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Add link object implementation to the application.
Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
All the actions associated with application pipelines
tables and ports are now implemented using the new action
APIs. Therefore, thousands of lines of code are eliminated
from the application. The reduced code size is easier to
maintain and extend.
Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
This patch adds support for meter configuration profiles.
Benefits: simplified configuration procedure, improved performance.
Q1: What is the configuration profile and why does it make sense?
A1: The configuration profile represents the set of configuration
parameters for a given meter object, such as the rates and sizes for
the token buckets. The configuration profile concept makes sense when
many meter objects share the same configuration, which is the typical
usage model: thousands of traffic flows are each individually metered
according to just a few service levels (i.e. profiles).
Q2: How is the configuration profile improving the performance?
A2: The performance improvement is achieved by reducing the memory
footprint of a meter object, which results in better cache utilization
for the typical case when large arrays of meter objects are used. The
internal data structures stored for each meter object contain:
a) Constant fields: Low level translation of the configuration
parameters that does not change post-configuration. This is
really duplicated for all meters that use the same
configuration. This is the configuration profile data that is
moved away from the meter object. Current size (implementation
dependent): srTCM = 32 bytes, trTCM = 32 bytes.
b) Variable fields: Time stamps and running counters that change
during the on-going traffic metering process. Current size
(implementation dependent): srTCM = 24 bytes, trTCM = 32 bytes.
Therefore, by moving the constant fields to a separate profile
data structure shared by all the meters with the same
configuration, the size of the meter object is reduced by ~50%.
Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Since the DPDK build now includes both static and shared libraries, we need
a new way to enable building the examples using either method from the one
installation. To do this, we add in a default "shared" target, and a
separate "static" target which links in the DPDK static libraries. In both
cases, the final application name is symlinked to the last-built static or
shared target, with both binaries able to co-exist in the build directory.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Change the example app Makefiles to query if DPDK is installed and
registered using pkg-config. If so, build directly using pkg-config info,
otherwise fall back to using the original build system with RTE_SDK and
RTE_TARGET
This commit changes the makefiles for the basic examples, i.e. those which
do not have multiple subdirectories underneath the main examples dir.
Examples not covered are:
* ethtool
* multi_process
* performance-thread
* quota_watermark
* netmap_compat
* server_node_efd
* vm_power_manager
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Luca Boccassi <bluca@debian.org>
Reorder the text in the makefiles, so that the app name and the source
files are listed first. This then will allow them to be shared later in a
combined makefile building with pkg-config and RTE_SDK-based build system.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: Luca Boccassi <bluca@debian.org>
Replace the BSD license header with the SPDX tag for files
with only an Intel copyright on them.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
In order to achieve fully reproducible builds, always use the same
inclusion order for headers in the Makefiles.
Signed-off-by: Luca Boccassi <luca.boccassi@gmail.com>
A dollar sign is missing and it is not needed because of VPATH.
Reported-by: Ilya V. Matveychikov <matvejchikov@gmail.com>
Suggested-by: Ferruh Yigit <ferruh.yigit@intel.com>
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Add a couple of additional functions that will allow to parse many types
of input parameters, i.e.: bool, 16, 32, 64 bits, hex, etc.
Signed-off-by: Piotr Azarewicz <piotrx.t.azarewicz@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Flow actions pipeline is an extension of flow-classification pipeline.
Some of the operations of flow classification pipeline such as traffic
metering/marking(for e.g. Single Rate Three Color Marker (srTCM), Two
Rate Three Color Marker trTCM)), policer can be performed separately in
flow action pipeline to avoid excessive computational burden on the CPU
core running the flow-classification pipeline. The Flow action pipeline
implements various function such as traffic metering, policer, stats.
Traffic mettering can configured as per the required context, for
examples- per user, per traffic class or both. These contexts can be
applied by specifying parameters in configuration file as shown below;
[PIPELINE1]
type = FLOW_ACTIONS
core = 1
pktq_in = RXQ0.0 RXQ1.0 RXQ2.0 RXQ3.0
pktq_out = TXQ0.0 TXQ1.0 TXQ2.0 TXQ3.0
n_flows = 65536
n_meters_per_flow = 1
flow_id_offset = 158
ip_hdr_offset = 142
color_offset = 64
The entries of flow and dscp tables of flow actions pipeline can be
modified through command-line interface. The commands to add or delete
entries to the flow table, DSCP(differentiated services code point)
table and for statistics collection, etc have been included. The key
functions such as Traffic Metering/marking and policer functions have
been implemented as flow-table action handler.
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Up till now pipeline was bound to thread selected in the initial config.
This patch allows binding pipeline to other threads at runtime using CLI
commands.
Signed-off-by: Maciej Gajdzica <maciejx.t.gajdzica@intel.com>
Signed-off-by: Piotr Azarewicz <piotrx.t.azarewicz@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Master pipeline is responsible for command line handling and
communicationg with all other pipelines via message queues. Removed
cmdline.c file, as its functionality will be split over multiple
pipeline files.
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Moved pipelines to separate folder, removed not needed pipelines and
modified Makefile to match that change.
Signed-off-by: Maciej Gajdzica <maciejx.t.gajdzica@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
After changes in config parser, app params struct is changed and
requires modifications in initialization procedures.
Signed-off-by: Maciej Gajdzica <maciejx.t.gajdzica@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
After loading configuration from a file, data integrity is checked.
Signed-off-by: Jasvinder Singh <jasvinder.singh@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
New syntax of config files is needed for ip_pipeline example
enhancements. Some old files are temporarily disabled in the Makefile.
It is part of a bigger change.
Signed-off-by: Pawel Wodkowski <pawelx.wodkowski@intel.com>
Acked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
This patch removes all references to RTE_MBUF_REFCNT, setting the refcnt
field in the mbuf struct permanently.
Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
It seems that RTE_MBUF_SCATTER_GATHER is not the proper name for the
feature it provides. "Scatter gather" means that data is stored using
several buffers. RTE_MBUF_REFCNT seems to be a better name for that
feature as it provides a reference counter for mbufs.
The macro RTE_MBUF_SCATTER_GATHER is poisoned to ensure this
modification is seen by drivers or applications using it.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
L3fwd-acl and ip pipeline apps were using old
x86_64-default-linuxapp-gcc as their default target,
instead of x86_64-native-linuxapp-gcc
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
This Packet Framework sample application illustrates the capabilities
of the Intel DPDK Packet Framework toolbox.
It creates different functional blocks used by a typical IPv4 framework like:
flow classification, firewall, routing, etc.
CPU cores are connected together through standard interfaces built on SW rings,
which each CPU core running a separate pipeline instance.
Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Tested-by: Waterman Cao <waterman.cao@intel.com>
Acked-by: Pablo de Lara Guarch <pablo.de.lara.guarch@intel.com>
Acked by: Ivan Boule <ivan.boule@6wind.com>
