crypto/qat: add multi-process handling of driver ID
As cryptodev driver_id is allocated per-process,
a corner case exists where binaries for primary and
secondary processes could have different driver_ids
if built differently. Add checking in qat PMD to catch and
handle the case where driver_ids are inconsistent.
This patch refactors qat data into structures
which are local to the process and structures which
are intended to be shared by primary and secondary
processes. This enables qat devices to be used by
multi process applications.
Akhil Goyal [Tue, 10 Dec 2019 12:50:33 +0000 (18:20 +0530)]
common/dpaax: remove unnecessary jump for PDCP
In case of LX2160, PROTOCOL command can be used in some of the PDCP
cases, in those the jump command prior to KEY command may not be
required.
The issue observed due to these JUMP command on LX2160 is that,
the CAAM gets stuck and the processing never get completed. The
system becomes unusable.
Akhil Goyal [Wed, 8 Jan 2020 12:52:31 +0000 (18:22 +0530)]
common/dpaax: fix 12-bit null auth case
In cases of NULL auth in PDCP, the descriptors
should be based on ALGORITHM command instead of
PROTOCOL command.
It was done in case of encap, but was missing in
decap.
Akhil Goyal [Thu, 4 Jun 2020 20:04:10 +0000 (01:34 +0530)]
crypto/dpaax_sec: fix inline query for descriptors
The maximum length of job descriptor which is formed
is 13 words and hence rta_inline_query should take
care of the max descriptor(shared + job) lengths and
thus find out of the key can be referenced or immediate.
Fixes: 05b12700cd4c ("crypto/dpaa_sec: support null algos for protocol offload") Fixes: 13273250eec5 ("crypto/dpaa2_sec: support AES-GCM and CTR") Cc: stable@dpdk.org Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com> Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
test/crypto-perf: add option to enable session HFN
Add a new option for PDCP cases to enable use of session
based fixed HFN value instead of per packet HFN which was
enabled by hfn override feature.
By default HFN override is enabled and if session based
fixed HFN need to be tested, add "--pdcp-ses-hfn-en" in the
command line.
As per current framework of PDCP testing, app can only support
either HFN override or fixed session HFN values but not both.
Now to enable both, either we duplicate all PDCP cases(>100)
for both override and fixed HFN. It will look clumsy as the
number of cases will be very high without much value addition.
Now to overcome this, we can do HFN override for Downlink cases
and fixed HFN for uplink cases. This way we will not loose the
test coverage and there will not be duplicacy in the test cases.
Akhil Goyal [Mon, 1 Jun 2020 17:17:45 +0000 (22:47 +0530)]
crypto/dpaax_sec: fix 18-bit PDCP cases with HFN override
In case of RTA_SEC_ERA = 8, where the length of shared desc
is large for some of PDCP cases, the descriptor buffer cannot
hold 2 extra words when HFN override is enabled. As a result,
the descriptor fails.
This patch converts one of the keys from immediate key to
reference key hence reducing the length of the descriptor.
Fixes: 2e4cbdb4b2c2 ("crypto/dpaax_sec: support PDCP U-Plane with integrity") Cc: stable@dpdk.org Signed-off-by: Akhil Goyal <akhil.goyal@nxp.com> Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
For SNOW and ZUC algos the offset value for enryption and decryption
is converted to bytes. Hence RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA
feature is not supported by the octeontx2 crypto pmd.
For SNOW and ZUC algos the offset value for enryption and decryption
is converted to bytes. Hence RTE_CRYPTODEV_FF_NON_BYTE_ALIGNED_DATA
feature is not supported by the octeontx crypto pmd.
Signed-off-by: David Coyle <david.coyle@intel.com> Signed-off-by: Mairtin o Loingsigh <mairtin.oloingsigh@intel.com> Acked-by: Akhil Goyal <akhil.goyal@nxp.com> Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
David Coyle [Fri, 3 Jul 2020 12:39:31 +0000 (13:39 +0100)]
test/crypto: add DOCSIS security cases
Add uplink and downlink DOCSIS unit test cases and vectors, to test
the combined DOCSIS Crypto-CRC support that has been added to the
rte_security library.
Signed-off-by: David Coyle <david.coyle@intel.com> Signed-off-by: Mairtin o Loingsigh <mairtin.oloingsigh@intel.com> Acked-by: Akhil Goyal <akhil.goyal@nxp.com> Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
David Coyle [Fri, 3 Jul 2020 12:39:30 +0000 (13:39 +0100)]
crypto/qat: support DOCSIS protocol
Add support to the QAT SYM PMD for the DOCSIS protocol, through the
rte_security API. This, therefore, includes adding support for the
rte_security API to this PMD.
Signed-off-by: David Coyle <david.coyle@intel.com> Signed-off-by: Mairtin o Loingsigh <mairtin.oloingsigh@intel.com>
David Coyle [Fri, 3 Jul 2020 12:39:29 +0000 (13:39 +0100)]
crypto/aesni_mb: support DOCSIS protocol
Add support to the AESNI-MB PMD for the DOCSIS protocol, through the
rte_security API. This, therefore, includes adding support for the
rte_security API to this PMD.
Signed-off-by: David Coyle <david.coyle@intel.com> Signed-off-by: Mairtin o Loingsigh <mairtin.oloingsigh@intel.com> Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
David Coyle [Fri, 3 Jul 2020 12:39:28 +0000 (13:39 +0100)]
cryptodev: add comments for DOCSIS protocol
Add a note to the rte_crypto_sym_op->auth.data fields to state that
for DOCSIS security protocol, these are used to specify the offset and
length of data over which the CRC is calculated.
Signed-off-by: David Coyle <david.coyle@intel.com> Signed-off-by: Mairtin o Loingsigh <mairtin.oloingsigh@intel.com> Acked-by: Akhil Goyal <akhil.goyal@nxp.com> Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
David Coyle [Fri, 3 Jul 2020 12:39:27 +0000 (13:39 +0100)]
security: support DOCSIS protocol
Add support for DOCSIS protocol to rte_security library. This support
currently comprises the combination of Crypto and CRC operations.
Signed-off-by: David Coyle <david.coyle@intel.com> Signed-off-by: Mairtin o Loingsigh <mairtin.oloingsigh@intel.com> Acked-by: Akhil Goyal <akhil.goyal@nxp.com> Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Adam Dybkowski [Mon, 8 Jun 2020 13:15:03 +0000 (15:15 +0200)]
crypto/qat: verify session IOVA
This patch adds the verification of the crypto session IOVA
that should be known (not zero) to proceed with the
session initialisation. In case of unknown IOVA
the error code -EINVAL is returned.
Signed-off-by: Adam Dybkowski <adamx.dybkowski@intel.com> Acked-by: Fiona Trahe <fiona.trahe@intel.com>
Adam Dybkowski [Mon, 8 Jun 2020 13:15:02 +0000 (15:15 +0200)]
cryptodev: verify session mempool element size
This patch adds the verification of the element size of the
mempool provided for the session creation. Returns the error
if the element size is too small to hold the session object.
David Marchand [Mon, 6 Jul 2020 20:52:34 +0000 (22:52 +0200)]
eal: add multiprocess disable API
The multiprocess feature has been implicitly enabled so far.
Applications might want to explicitly disable like when using the
non-EAL threads registration API.
Signed-off-by: David Marchand <david.marchand@redhat.com> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
David Marchand [Mon, 6 Jul 2020 20:52:33 +0000 (22:52 +0200)]
mempool/bucket: handle non-EAL lcores
Convert to new lcore API to support non-EAL lcores.
Signed-off-by: David Marchand <david.marchand@redhat.com> Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
David Marchand [Mon, 6 Jul 2020 20:52:31 +0000 (22:52 +0200)]
eal: add lcore init callbacks
DPDK components and applications can have their say when a new lcore is
initialized. For this, they can register a callback for initializing and
releasing their private data.
Signed-off-by: David Marchand <david.marchand@redhat.com> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
David Marchand [Mon, 6 Jul 2020 20:52:30 +0000 (22:52 +0200)]
eal: register non-EAL threads as lcores
DPDK allows calling some part of its API from a non-EAL thread but this
has some limitations.
OVS (and other applications) has its own thread management but still
want to avoid such limitations by hacking RTE_PER_LCORE(_lcore_id) and
faking EAL threads potentially unknown of some DPDK component.
Introduce a new API to register non-EAL thread and associate them to a
free lcore with a new NON_EAL role.
This role denotes lcores that do not run DPDK mainloop and as such
prevents use of rte_eal_wait_lcore() and consorts.
Multiprocess is not supported as the need for cohabitation with this new
feature is unclear at the moment.
Signed-off-by: David Marchand <david.marchand@redhat.com> Acked-by: Andrew Rybchenko <arybchenko@solarflare.com> Acked-by: Thomas Monjalon <thomas@monjalon.net> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
David Marchand [Mon, 6 Jul 2020 20:52:27 +0000 (22:52 +0200)]
eal: introduce thread init helper
Introduce a helper responsible for initialising the per thread context.
We can then have a unified context for EAL and non-EAL threads and
remove copy/paste'd OS-specific helpers.
Per EAL thread CPU affinity setting is separated from the thread init.
It is to accommodate with Windows EAL where CPU affinity is not set at
the moment.
Besides, having affinity set by the master lcore in FreeBSD and Linux
will make it possible to detect errors rather than panic in the child
thread. But the cleanup when such an event happens is left for later.
A side-effect of this patch is that control threads can now use
recursive locks (rte_gettid() was not called before).
Signed-off-by: David Marchand <david.marchand@redhat.com> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
David Marchand [Mon, 6 Jul 2020 20:52:26 +0000 (22:52 +0200)]
eal: fix multiple definition of per lcore thread id
Because of the inline accessor + static declaration in rte_gettid(),
we end up with multiple symbols for RTE_PER_LCORE(_thread_id).
Each compilation unit will pay a cost when accessing this information
for the first time.
Change the barrier APIs for IO to reflect that Armv8-a is other-multi-copy
atomicity memory model.
Armv8-a memory model has been strengthened to require
other-multi-copy atomicity. This property requires memory accesses
from an observer to become visible to all other observers
simultaneously [3]. This means
a) A write arriving at an endpoint shared between multiple CPUs is
visible to all CPUs
b) A write that is visible to all CPUs is also visible to all other
observers in the shareability domain
This allows for using cheaper DMB instructions in the place of DSB
for devices that are visible to all CPUs (i.e. devices that DPDK
caters to).
Please refer to [1], [2] and [3] for more information.
Igor Romanov [Tue, 7 Jul 2020 10:45:25 +0000 (11:45 +0100)]
test/service: check active state on two lcores
The test checks that the service may be active API works
when there are two cores: a non-service lcore and a service one.
The API notes to take care when checking the status of a running
service, but the test setup allows for a safe usage in that case.
Signed-off-by: Igor Romanov <igor.romanov@oktetlabs.ru> Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com> Acked-by: Harry van Haaren <harry.van.haaren@intel.com> Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
To call the rte_rawdev_info_get() function, the user currently has to know
the underlying type of the device in order to pass an appropriate structure
or buffer as the dev_private pointer in the info structure. By allowing a
NULL value for this field, we can skip getting the device-specific info and
just return the generic info - including the device name and driver, which
can be used to determine the device type - to the user.
This ensures that basic info can be get for all rawdevs, without knowing
the type, and even if the info driver API call has not been implemented for
the device.
Cc: stable@dpdk.org Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
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: b5dc795a8a55 ("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>
Haiyue Wang [Fri, 3 Jul 2020 14:57:18 +0000 (22:57 +0800)]
vfio: support VF token
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>
Haiyue Wang [Fri, 3 Jul 2020 14:57:17 +0000 (22:57 +0800)]
eal: fix uuid header dependencies
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: 6bc67c497a51 ("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>
Yunjian Wang [Sat, 16 May 2020 07:58:39 +0000 (15:58 +0800)]
vfio: remove unused variable
The 'group_status' has never been used and can be removed.
Fixes: 94c0776b1bad ("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: 26cc3bbe4dc0 ("eal: add lcore accessors") Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Acked-by: David Marchand <david.marchand@redhat.com>
eal/armv8: fix timer frequency calibration with PMU
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: f91bcbb2d9a6 ("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>
David Marchand [Fri, 26 Jun 2020 08:16:36 +0000 (10:16 +0200)]
build: remove special versioning for non stable libraries
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).
Signed-off-by: David Marchand <david.marchand@redhat.com> Acked-by: Ray Kinsella <mdr@ashroe.eu> Acked-by: Bruce Richardson <bruce.richardson@intel.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.
Alan Dewar [Thu, 25 Jun 2020 09:59:30 +0000 (10:59 +0100)]
sched: fix port time rounding
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.
Ori Kam [Mon, 6 Jul 2020 17:36:48 +0000 (17:36 +0000)]
regexdev: add core functions
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>
Jerin Jacob [Mon, 6 Jul 2020 17:36:46 +0000 (17:36 +0000)]
regexdev: introduce API
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: 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>
David Marchand [Mon, 6 Jul 2020 08:00:22 +0000 (10:00 +0200)]
devtools: fix check of variable declaration inside for
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:]].
Pavan Nikhilesh [Mon, 29 Jun 2020 01:33:28 +0000 (07:03 +0530)]
event/octeontx2: improve datapath memory locality
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.
Pavan Nikhilesh [Mon, 29 Jun 2020 01:33:27 +0000 (07:03 +0530)]
event/octeontx2: fix sub event type
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.
Harry van Haaren [Tue, 16 Jun 2020 16:56:03 +0000 (17:56 +0100)]
examples/eventdev: fix 32-bit coremask
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>
Harman Kalra [Fri, 15 May 2020 11:21:24 +0000 (16:51 +0530)]
event/octeontx: fix memory corruption
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.
Bruce Richardson [Fri, 26 Jun 2020 14:59:57 +0000 (15:59 +0100)]
eal: restrict default plugin path to shared lib mode
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>
eal: load only shared libs from driver plugin directories
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>
eal: remove unnecessary null-termination in plugin path
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.
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.
examples/l2fwd: add forwarding port mapping option
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.
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>
Thomas Monjalon [Wed, 1 Jul 2020 07:31:34 +0000 (09:31 +0200)]
build: remove special handling for node library
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: e2db26f76673 ("build: always link whole DPDK static libraries") Signed-off-by: Thomas Monjalon <thomas@monjalon.net> Tested-by: Jerin Jacob <jerinj@marvell.com>