This commit fixes the setting of relative rpath on dpdk-test for
drivers ($libdir/dpdk/pmd-$abiver) to the correct absolute rpath
($prefix$libdir/dpdk/pmd-$abiver).
Fixes: b5dc795a8a ("test: build app with meson as dpdk-test")
Cc: stable@dpdk.org
Signed-off-by: Timothy Redaelli <tredaelli@redhat.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
The Linux kernel module vfio-pci introduces the VF token to enable
SR-IOV support since 5.7.
The VF token can be set by a vfio-pci based PF driver and must be known
by the vfio-pci based VF driver in order to gain access to the device.
Since the vfio-pci module uses the VF token as internal data to provide
the collaboration between SR-IOV PF and VFs, so DPDK can use the same
VF token for all PF devices by specifying the related EAL option.
Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Andrew Rybchenko <arybchenko@solarflare.com>
Tested-by: Harman Kalra <hkalra@marvell.com>
Add the dependent header files explicitly, so that the user just needs
to include the 'rte_uuid.h' header file directly to avoid compile error:
(1). rte_uuid.h:97:55: error: unknown type name ‘size_t’
(2). rte_uuid.h:58:2: error: implicit declaration of function ‘memcpy’
Fixes: 6bc67c497a ("eal: add uuid API")
Cc: stable@dpdk.org
Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
Acked-by: David Marchand <david.marchand@redhat.com>
The startup of VFIO is too noisy. Logging is expensive on some
systems, and distracting to the user.
It should not be logging at NOTICE level, reduce it to INFO level.
It really should be DEBUG here but that would hide it by default.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
The 'group_status' has never been used and can be removed.
Fixes: 94c0776b1b ("vfio: support hotplug")
Cc: stable@dpdk.org
Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
If rte_lcore_index() is asked to give the index of the
current lcore (argument -1) and is called from a non-EAL thread
then it would invalid result. The result would come
lcore_config[-1].core_index which is some other data in the
per-thread area.
The resolution is to return -1 which is what rte_lcore_index()
returns if handed an invalid lcore.
Same issue existed with rte_lcore_to_cpu_id().
Bugzilla ID: 446
Fixes: 26cc3bbe4d ("eal: add lcore accessors")
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: David Marchand <david.marchand@redhat.com>
Change the inline functions to use __rte_always_inline to be
consistent with rest of the inline functions.
Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
get_tsc_freq uses 'nanosleep' system call to calculate the CPU
frequency. However, 'nanosleep' results in the process getting
un-scheduled. The kernel saves and restores the PMU state. This
ensures that the PMU cycles are not counted towards a sleeping
process. When RTE_ARM_EAL_RDTSC_USE_PMU is defined, this results
in incorrect CPU frequency calculation. This logic is replaced
with generic counter based loop.
Bugzilla ID: 450
Fixes: f91bcbb2d9 ("eal/armv8: use high-resolution cycle counter")
Cc: stable@dpdk.org
Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
Reviewed-by: Dharmik Thakkar <dharmik.thakkar@arm.com>
Reviewed-by: Phil Yang <phil.yang@arm.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
The experimental tags were removed, but the comment
is still having API classification as EXPERIMENTAL
Fixes: 931cc531aa ("rawdev: remove experimental tag")
Cc: stable@dpdk.org
Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: David Marchand <david.marchand@redhat.com>
The following libraries are experimental, all of their functions can
be changed or removed:
- librte_bbdev
- librte_bpf
- librte_compressdev
- librte_fib
- librte_flow_classify
- librte_graph
- librte_ipsec
- librte_node
- librte_rcu
- librte_rib
- librte_stack
- librte_telemetry
Their status is properly announced in MAINTAINERS.
Remind this status in their headers in a common fashion (aligned to ABI
docs).
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Now that all libraries have a single version, we can drop the empty
stable blocks that had been added when moving symbols from stable to
internal ABI.
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Having a special versioning for experimental/internal libraries put a
additional maintenance cost while this status is already announced in
MAINTAINERS and the library headers/documentation.
Following discussions and vote at 05/20 TB meeting [1], use a single
versioning for all libraries in DPDK.
Note: for the ABI check, an exception [2] had been added when tweaking
this special versioning [3].
Prefer explicit libabigail rules (which will be dropped in 20.11).
1: https://mails.dpdk.org/archives/dev/2020-May/168450.html
2: https://git.dpdk.org/dpdk/commit/?id=23d7ad5db41c
3: https://git.dpdk.org/dpdk/commit/?id=ec2b8cd7ed69
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Ray Kinsella <mdr@ashroe.eu>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Inclusion of the endian.h header is set only for Linux OS.
Windows endianness will be determined by the predefined
__BYTE_ORDER__ macro.
Signed-off-by: Tal Shnaiderman <talshn@mellanox.com>
Some EAL functions are used by mempool lib but not exported on Windows.
The functions are exported.
Added mempool to supported libraries for Windows compilation.
Signed-off-by: Fady Bader <fady@mellanox.com>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
Function versioning implementation is not supported by Windows.
Function versioning is disabled on Windows.
Signed-off-by: Fady Bader <fady@mellanox.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
The QoS scheduler works off port time that is computed from the number
of CPU cycles that have elapsed since the last time the port was
polled. It divides the number of elapsed cycles to calculate how
many bytes can be sent, however this division can generate rounding
errors, where some fraction of a byte sent may be lost.
Lose enough of these fractional bytes and the QoS scheduler
underperforms. The problem is worse with low bandwidths.
To compensate for this rounding error this fix doesn't advance the
port's time_cpu_cycles by the number of cycles that have elapsed,
but by multiplying the computed number of bytes that can be sent
(which has been rounded down) by number of cycles per byte.
This will mean that port's time_cpu_cycles will lag behind the CPU
cycles momentarily. At the next poll, the lag will be taken into
account.
Fixes: de3cfa2c98 ("sched: initial import")
Cc: stable@dpdk.org
Signed-off-by: Alan Dewar <alan.dewar@att.com>
Acked-by: Jasvinder Singh <jasvinder.singh@intel.com>
This commit introduce the API that is needed by the RegEx devices in
order to work with the RegEX lib.
During the probe of a RegEx device, the device should configure itself,
and allocate the resources it requires.
On completion of the device init, it should call the
rte_regex_dev_register in order to register itself as a RegEx device.
Signed-off-by: Ori Kam <orika@mellanox.com>
Signed-off-by: Parav Pandit <parav@mellanox.com>
Acked-by: Guy Kaneti <guyk@marvell.com>
This commit introduce the rte_regexdev_core.h file.
This file holds internal structures and API that are used by
the regexdev.
Signed-off-by: Ori Kam <orika@mellanox.com>
Acked-by: Guy Kaneti <guyk@marvell.com>
As RegEx usage become more used by DPDK applications, for example:
* Next Generation Firewalls (NGFW)
* Deep Packet and Flow Inspection (DPI)
* Intrusion Prevention Systems (IPS)
* DDoS Mitigation
* Network Monitoring
* Data Loss Prevention (DLP)
* Smart NICs
* Grammar based content processing
* URL, spam and adware filtering
* Advanced auditing and policing of user/application security policies
* Financial data mining - parsing of streamed financial feeds
* Application recognition.
* Dmemory introspection.
* Natural Language Processing (NLP)
* Sentiment Analysis.
* Big data database acceleration.
* Computational storage.
Number of PMD providers started to work on HW implementation,
along side with SW implementations.
This lib adds the support for those kind of devices.
The RegEx Device API is composed of two parts:
- The application-oriented RegEx API that includes functions to setup
a RegEx device (configure it, setup its queue pairs and start it),
update the rule database and so on.
- The driver-oriented RegEx API that exports a function allowing
a RegEx poll Mode Driver (PMD) to simultaneously register itself as
a RegEx device driver.
RegEx device components and definitions:
+-----------------+
| |
| o---------+ rte_regexdev_[en|de]queue_burst()
| PCRE based o------+ | |
| RegEx pattern | | | +--------+ |
| matching engine o------+--+--o | | +------+
| | | | | queue |<==o===>|Core 0|
| o----+ | | | pair 0 | | |
| | | | | +--------+ +------+
+-----------------+ | | |
^ | | | +--------+
| | | | | | +------+
| | +--+--o queue |<======>|Core 1|
Rule|Database | | | pair 1 | | |
+------+----------+ | | +--------+ +------+
| Group 0 | | |
| +-------------+ | | | +--------+ +------+
| | Rules 0..n | | | | | | |Core 2|
| +-------------+ | | +--o queue |<======>| |
| Group 1 | | | pair 2 | +------+
| +-------------+ | | +--------+
| | Rules 0..n | | |
| +-------------+ | | +--------+
| Group 2 | | | | +------+
| +-------------+ | | | queue |<======>|Core n|
| | Rules 0..n | | +-------o pair n | | |
| +-------------+ | +--------+ +------+
| Group n |
| +-------------+ |<-------rte_regexdev_rule_db_update()
| | | |<-------rte_regexdev_rule_db_compile_activate()
| | Rules 0..n | |<-------rte_regexdev_rule_db_import()
| +-------------+ |------->rte_regexdev_rule_db_export()
+-----------------+
RegEx: A regular expression is a concise and flexible means for matching
strings of text, such as particular characters, words, or patterns of
characters. A common abbreviation for this is â~@~\RegExâ~@~].
RegEx device: A hardware or software-based implementation of RegEx
device API for PCRE based pattern matching syntax and semantics.
PCRE RegEx syntax and semantics specification:
http://regexkit.sourceforge.net/Documentation/pcre/pcrepattern.html
RegEx queue pair: Each RegEx device should have one or more queue pair to
transmit a burst of pattern matching request and receive a burst of
receive the pattern matching response. The pattern matching
request/response embedded in *rte_regex_ops* structure.
Rule: A pattern matching rule expressed in PCRE RegEx syntax along with
Match ID and Group ID to identify the rule upon the match.
Rule database: The RegEx device accepts regular expressions and converts
them into a compiled rule database that can then be used to scan data.
Compilation allows the device to analyze the given pattern(s) and
pre-determine how to scan for these patterns in an optimized fashion that
would be far too expensive to compute at run-time. A rule database
contains a set of rules that compiled in device specific binary form.
Match ID or Rule ID: A unique identifier provided at the time of rule
creation for the application to identify the rule upon match.
Group ID: Group of rules can be grouped under one group ID to enable
rule isolation and effective pattern matching. A unique group identifier
provided at the time of rule creation for the application to identify
the rule upon match.
Scan: A pattern matching request through *enqueue* API.
It may possible that a given RegEx device may not support all the
features
of PCRE. The application may probe unsupported features through
struct rte_regexdev_info::pcre_unsup_flags
By default, all the functions of the RegEx Device API exported by a PMD
are lock-free functions which assume to not be invoked in parallel on
different logical cores to work on the same target object. For instance,
the dequeue function of a PMD cannot be invoked in parallel on two logical
cores to operates on same RegEx queue pair. Of course, this function
can be invoked in parallel by different logical core on different queue
pair. It is the responsibility of the upper level application to
enforce this rule.
In all functions of the RegEx API, the RegEx device is
designated by an integer >= 0 named the device identifier *dev_id*
At the RegEx driver level, RegEx devices are represented by a generic
data structure of type *rte_regexdev*.
RegEx devices are dynamically registered during the PCI/SoC device
probing phase performed at EAL initialization time.
When a RegEx device is being probed, a *rte_regexdev* structure and
a new device identifier are allocated for that device. Then, the
regexdev_init() function supplied by the RegEx driver matching the
probed device is invoked to properly initialize the device.
The role of the device init function consists of resetting the hardware
or software RegEx driver implementations.
If the device init operation is successful, the correspondence between
the device identifier assigned to the new device and its associated
*rte_regexdev* structure is effectively registered.
Otherwise, both the *rte_regexdev* structure and the device identifier
are freed.
The functions exported by the application RegEx API to setup a device
designated by its device identifier must be invoked in the following
order:
- rte_regexdev_configure()
- rte_regexdev_queue_pair_setup()
- rte_regexdev_start()
Then, the application can invoke, in any order, the functions
exported by the RegEx API to enqueue pattern matching job, dequeue
pattern matching response, get the stats, update the rule database,
get/set device attributes and so on
If the application wants to change the configuration (i.e. call
rte_regexdev_configure() or rte_regexdev_queue_pair_setup()), it must
call rte_regexdev_stop() first to stop the device and then do the
reconfiguration before calling rte_regexdev_start() again. The enqueue and
dequeue functions should not be invoked when the device is stopped.
Finally, an application can close a RegEx device by invoking the
rte_regexdev_close() function.
Each function of the application RegEx API invokes a specific function
of the PMD that controls the target device designated by its device
identifier.
For this purpose, all device-specific functions of a RegEx driver are
supplied through a set of pointers contained in a generic structure of
type *regexdev_ops*.
The address of the *regexdev_ops* structure is stored in the
*rte_regexdev* structure by the device init function of the RegEx driver,
which is invoked during the PCI/SoC device probing phase, as explained
earlier.
In other words, each function of the RegEx API simply retrieves the
*rte_regexdev* structure associated with the device identifier and
performs an indirect invocation of the corresponding driver function
supplied in the *regexdev_ops* structure of the *rte_regexdev*
structure.
For performance reasons, the address of the fast-path functions of the
RegEx driver is not contained in the *regexdev_ops* structure.
Instead, they are directly stored at the beginning of the *rte_regexdev*
structure to avoid an extra indirect memory access during their
invocation.
RTE RegEx device drivers do not use interrupts for enqueue or dequeue
operation. Instead, RegEx drivers export Poll-Mode enqueue and dequeue
functions to applications.
The *enqueue* operation submits a burst of RegEx pattern matching
request to the RegEx device and the *dequeue* operation gets a burst of
pattern matching response for the ones submitted through *enqueue*
operation.
Typical application utilisation of the RegEx device API will follow the
following programming flow.
- rte_regexdev_configure()
- rte_regexdev_queue_pair_setup()
- rte_regexdev_rule_db_update() Needs to invoke if precompiled rule
database not
provided in rte_regexdev_config::rule_db for rte_regexdev_configure()
and/or application needs to update rule database.
- rte_regexdev_rule_db_compile_activate() Needs to invoke if
rte_regexdev_rule_db_update function was used.
- Create or reuse exiting mempool for *rte_regex_ops* objects.
- rte_regexdev_start()
- rte_regexdev_enqueue_burst()
- rte_regexdev_dequeue_burst()
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Signed-off-by: Ori Kam <orika@mellanox.com>
An expression with a space is split by the awk script resulting in
false positive for any patch matching any of the two part of the
expression.
Fix this by using [[:space:]].
Fixes: 43e73483a4 ("devtools: forbid variable declaration inside for")
Signed-off-by: David Marchand <david.marchand@redhat.com>
Fix displayed filename by adjusting the extraction from the patch.
Before:
Warning in /lib/librte_eal/linux/eal.c:
After:
Warning in lib/librte_eal/linux/eal.c:
Fixes: 7413e7f2ae ("devtools: alert on new calls to exit from libs")
Cc: stable@dpdk.org
Signed-off-by: David Marchand <david.marchand@redhat.com>
When event device is transmitting packet on OCTEONTX2 it needs to access
the destined ethernet device TXq data.
Currently, we get the TXq data through rte_eth_devices global array.
Instead save the TXq address inside event port memory.
Cc: stable@dpdk.org
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
In OCTEONTX2 event device we use sub_event_type to store the ethernet
port identifier when we receive work from OCTEONTX2 ethernet device.
This violates the event device spec as sub_event_type should be 0 in
the initial receive stage.
Set sub_event_type to 0 after copying the port id.
Fixes: 0fe4accd8e ("event/octeontx2: add Rx adapter fastpath ops")
Cc: stable@dpdk.org
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
When event device is re-configured maintain the event queue to event port
links and event port status instead of resetting them.
Fixes: cd24e70258 ("event/octeontx2: add device configure function")
Cc: stable@dpdk.org
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
This commit fixes a bug in 32-bit environments when a core mask greater
than 32-bits is requested. The fix is to convert the bitmask logic to
64 bits, aligning 64 and 32 bit implementations.
Fixes: adb5d548 ("examples/eventdev_pipeline_sw_pmd: add sample app")
Cc: stable@dpdk.org
Reported-by: Jun W Zhou <junx.w.zhou@intel.com>
Suggested-by: Mao Jiang <maox.jiang@intel.com>
Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
Since PMD enqueues a single event at a time, fixing the issue by
passing 1 rather than nb_events to avoid any out of bound access as
reported by coverity.
Coverity issue: 358447
Fixes: 56a96aa424 ("event/octeontx: add framework for Rx/Tx offloads")
Cc: stable@dpdk.org
Signed-off-by: Harman Kalra <hkalra@marvell.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
RTE_TRACE_POINT_DEFINE and RTE_TRACE_POINT_REGISTER must come in pairs.
Merge them and let RTE_TRACE_POINT_REGISTER handle the constructor part.
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
When using statically linked DPDK binaries, the EAL checks the default PMD
path and tries to load any drivers there, despite the fact that all drivers
are normally linked into the binary. This behaviour can cause issues if
the PMD path and lib dir is configured to a non-standard location which is
not in the ld.so.conf paths, e.g. a build with prefix set to a home
directory location. In a case such as this, EAL will try and
(unnecessarily) load the .so driver files but that load will fail as their
dependent libraries, such as ethdev, for example, will not be found.
Because of this, it is better if statically linked DPDK apps do not load
drivers from the standard paths automatically. The user can always have
this behaviour by explicitly specifying the path using -d flag, if so
desired.
Not loading the libraries automatically can also prevent potential issues
with a user building and running a statically-linked DPDK binary based off
a private copy of DPDK, while there exists on the same machine a
system-wide installation of DPDK in the default locations. Without this
change, the system-installed drivers will be loaded to the binary alongside
the statically-linked drivers, which is not what the user would have
intended.
To detect whether we are in a statically or dynamically linked binary, we
can have EAL try to get a dlopen handle to its own shared library, by
calling dlopen with the RTLD_NOLOAD flag. This will return NULL if there is
no such shared lib loaded i.e. the code is executing from a static library,
or a handle to the lib if it is loaded.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Tested-by: Sunil Pai G <sunil.pai.g@intel.com>
When loading a directory of drivers, we check the same hierarchy multiple
times. If we just cache the last directory checked, this avoids repeated
checks of the same path, since all drivers in that path have been added to
the list consecutively.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Any paths on the system which are world-writable are insecure and should
not be used for loading drivers. Therefore, whenever an absolute or
relative driver path is passed to EAL, check for world-writability and
don't load any drivers from that path if it is insecure. Drivers loaded
from system locations i.e. those passed without any path info and found
automatically by the loader, are excluded from these checks as system paths
are assumed to be secure.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
When we pass a "-d" flag to EAL pointing to a directory, we attempt to load
all files in that directory as driver plugins, irrespective of file type.
This procludes using e.g. the build/drivers directory, as a driver source
since it contains static libs and other files as well as the shared
objects.
By filtering out any files whose filename does not end in ".so", we can
improve usability by allowing other non-driver files to be present in the
driver directory.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Since strlcpy always null-terminates, and the buffer is zeroed before copy
anyway, there is no need to explicitly zero the end of the character
array, or to limit the bytes that strlcpy can write.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Rather than checking the binutils version number, which can lead to
unnecessary disabling of AVX512 if fixes have been backported to distro
versions, we can instead check the output of "as" from binutils to see if
it is correct.
The check in the script uses the minimal assembly reproduction code posted
to the public bug tracker for gcc/binutils for those issues [1]. If the
binutils bug is present, the instruction parameters - specifically the
displacement parameter - will be different in the disassembled output
compared to the input. Therefore the check involves assembling a single
instruction and disassembling it again, checking that the two match.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90028
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Tested-by: Harry van Haaren <harry.van.haaren@intel.com>
When building with meson, the default size of virtual address space
reserved for mapping pages was globally set at 512GB, which is too big for
use in 32-bit processes. To match the behaviour with "make", we configure
this to be 512GB for 64-bit and 2GB for 32-bit builds.
Bugzilla ID: 498
Fixes: 66cc45e293 ("mem: replace memseg with memseg lists")
Cc: stable@dpdk.org
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Tested-by: Ferruh Yigit <ferruh.yigit@intel.com>
Current l2fwd application statically configures adjacent ports as
destination ports for forwarding the traffic.
Add a portmap option to pass the forwarding port pair mapping which allows
the user to configure forwarding port mapping.
If no portmap argument is specified, destination port map is not
changed and traffic gets forwarded with existing mapping.
To align port/queue configuration of each lcore with destination port
map, port/queue configuration of each lcore gets modified when portmap
option is specified.
Ex: ./l2fwd -c 0xff -- -p 0x3f -q 2 --portmap="(0,3)(1,4)(2,5)"
With above portmap option, traffic received from portid = 0 gets forwarded
to port = 3 and vice versa, similarly traffic gets forwarded on other port
pairs (1,4) and (2,5)
Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com>
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Acked-by: Andrzej Ostruszka <aostruszka@marvell.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
The node library had a need of being linked as a whole
to make some constructors effective.
Now that all libraries are linked with --whole-archive,
there is no need to have this library separate.
Fixes: e2db26f766 ("build: always link whole DPDK static libraries")
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Tested-by: Jerin Jacob <jerinj@marvell.com>
Introduce the RTE_LOG_REGISTER macro to avoid the code duplication
in the logtype registration process.
It is a wrapper macro for declaring the logtype, registering it and
setting its level in the constructor context.
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Adam Dybkowski <adamx.dybkowski@intel.com>
Acked-by: Sachin Saxena <sachin.saxena@nxp.com>
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
Rename test_ring_peek_stress to test_ring_mt_peek_stress to
keep same naming conventions for ST and MT test cases.
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Introduce new test case to test ST peek API.
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
Rework test code to reduce code complexity for the compiler and
bring down compilation time and memory consumption.
Current test_ring_enqueue/test_ring_dequeue functions contain
too many branches and it takes compiler a lot of effort to resolve all
of them at compile time.
So the patch replaces these branchy function invocations
with an array of function pointers (test_enqdeq_impl[]).
That way compiler knows straightway which function to use
for each particular case.
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Acked-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
The Linux checkpatch default is warning on the use of ENOSYS.
This is allowed in DPDK API.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
When building an ABI reference with meson, some static libraries
are built and linked in apps. They are useless and take a lot of space.
Those binaries, and other useless files (examples and doc files)
in the share/ directory, are removed after being installed.
In order to save time when building the ABI reference,
the examples (which are not installed anyway) are not compiled.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: David Marchand <david.marchand@redhat.com>
Some compilers raise an error when declaring a variable
in the middle of a function. This is a C99 allowance.
Even if DPDK switches globally to C99 or C11 standard,
the coding rules are for declarations at the beginning
of a block:
http://doc.dpdk.org/guides/contributing/coding_style.html#local-variables
This coding style is enforced by adding a check of
the common patterns like "for (int i;"
The occurrences of the checked pattern are fixed:
'for *(\(char\|u\?int\|unsigned\|s\?size_t\)'
In the file dpaa2_sparser.c, the fix is to remove the unused macros.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: David Marchand <david.marchand@redhat.com>
Add the --as-needed linker flag to the DPDK library list in the pkg-config
file so as to prevent overlinking. Without this flag, when linking
statically using flags from $(pkg-config --static --libs libdpdk), all DPDK
drivers and libs were statically linked in, but the binary was also
requiring all the shared versions be present to run.
The real root-cause of this issue is that the DPDK libraries need to be
duplicated in the linker command when doing static linking, due to the
behaviour of pkg-config, but since that behaviour cannot be easily changed,
this is a simple workaround to avoid problems.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Acked-by: Sunil Pai G <sunil.pai.g@intel.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Rather than setting -Bstatic in the linker flags when doing a static link,
and then having to explicitly set -Bdynamic again afterwards, we can update
the pkg-config file to use -l:libfoo.a syntax to explicitly refer to the
static library in question. Since this syntax is not supported by meson's
pkg-config module directly, we can post-process the .pc files instead to
adjust them.
Once done, we can simplify the examples' makefiles and the docs by removing
the explicit static flag.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Acked-by: Sunil Pai G <sunil.pai.g@intel.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
When calling pkg-config --static --libs, pkg-config will always output the
regular libs first, and then the extra libs from Libs.private field,
since the assumption is that those are additional dependencies for building
statically that the .a files depend upon.
However, for DPDK, we only link the driver files for static builds, and
those need to come *before* the regular libraries. To get this result, we
need two pkgconfig files for DPDK, one for the shared libs, and a second
for the static libs and drivers, which depends upon the first. Using a
dependency means that the shared libs are printed only after the
Libs.private field rather than before.
Without this patch, the linking works in DPDK because in all cases we
specify the libraries after the drivers in the Libs.private line, ensuring
that the references to the libs from the drivers can be resolved. The
current output is therefore of the form, "(shared)libs, drivers,
(static)libs", while after this patch the output is, "drivers,
(static)libs, (shared)libs". The former case will not work if we use the
--whole-archive flag on the static libs as it will lead to duplicate
definitions due to some references having been previously resolved from the
shared libraries. By ensuring the shared libraries come last in the link
link, this issue does not occur, as duplicate references when linking the
shared libs will be ignored.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Luca Boccassi <bluca@debian.org>
Acked-by: Sunil Pai G <sunil.pai.g@intel.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
