Since we allow line lengths of up to 100, and the CI checkpatches job
only check for that amount, the rest of our tooling and docs should
reflect this reality. Therefore we can:
* adjust the editorconfig to use that value, to save editors (e.g. vim)
from automatically wrapping lines at 80 characters when typing.
[Since python checkers all seem to expect 79 character lines max, add
for python only a 79-char max line length.]
* change the default line length setting in checkpatches script to 100
so as it matches CI and pre-merge checks.
* update the docs to clarify that while 80 chars is recommended, up to
100 characters is acceptable.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Chenbo Xia <chenbo.xia@intel.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
Acked-by: Conor Walsh <conor.walsh@intel.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
The problem is solved using Rx metadata delivery negotiation API [1].
[1] commit f6d8a6d3fa ("ethdev: negotiate delivery of packet metadata from HW to PMD")
Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
ENAv2 device requires write combining support which isn't supported by
the upstream vfio-pci. amzn-driver repository provided non-upstream
patch to enable this feature and it was linked directly by the ENA PMD
guide.
To avoid custom kernel patch linking, the user is now guided to the AWS
ENA PMD documentation, which describes vfio-pci and ENAv2 issue more
deeply with possible workarounds on how to resolve it.
Signed-off-by: Michal Krawczyk <mk@semihalf.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Update the software dependency link because of website shutdown.
Netcope Technologies was recently renamed to Magmio and no longer
provides packages and support for the FPGA cards and NDK platform.
However the project Liberouter@CESNET continues with the maintenance
of Network Development Kit and cooperates on the development of high
speed network FPGA cards as well.
Signed-off-by: Martin Spinler <spinler@cesnet.cz>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Some duplicate words were detected with a script.
Fixes: fdec9301f5 ("doc: add flow classify guides")
Fixes: 4dc6d8e63c ("doc: add graph library guide")
Fixes: 30d3aa861d ("doc: rework VM power manager user guide")
Fixes: 0d547ed037 ("examples/ipsec-secgw: support configuration file")
Fixes: e64833f227 ("examples/l2fwd-keepalive: add sample application")
Cc: stable@dpdk.org
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: David Marchand <david.marchand@redhat.com>
In the view of enabling unified driver for octeontx2(cn9k)/
octeontx3(cn10k), removing drivers/octeontx2 drivers and
replace with drivers/cnxk/ which supports both octeontx2(cn9k)
and octeontx3(cn10k) SoCs.
Signed-off-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Akhil Goyal <gakhil@marvell.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: David Marchand <david.marchand@redhat.com>
Add tested Intel platforms with Intel NICs to v21.11 release note.
Signed-off-by: Yan Xia <yanx.xia@intel.com>
Acked-by: Xueqin Lin <xueqin.lin@intel.com>
To enable bifurcated device support, rtnl_lock is released before calling
userspace callbacks and asynchronous requests are enabled.
But these changes caused more issues, like bug #809, #816. To reduce the
scope of the problems, the bifurcated device support related changes are
only enabled when it is requested explicitly with new 'enable_bifurcated'
module parameter.
And bifurcated device support is disabled by default.
So the bifurcated device related problems are isolated and they can be
fixed without impacting all use cases.
Bugzilla ID: 816
Fixes: 631217c761 ("kni: fix kernel deadlock with bifurcated device")
Cc: stable@dpdk.org
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Igor Ryzhov <iryzhov@nfware.com>
Updated AESNI MB and AESNI GCM, KASUMI, ZUC and SNOW3G PMD documentation
guides with information about the latest Intel IPSec Multi-buffer
library supported.
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
This library can be made optional.
drivers/gpu and app/test-gpudev depend on this library,
so they are automatically disabled if the lib is disabled.
Signed-off-by: Elena Agostini <eagostini@nvidia.com>
Users are confused with a feature with "P", added necessary
explanation for this.
Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
These edits affect the outermost header in the current processing state
of the packet, which might have been decapsulated by prior action DECAP.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
DMA on SN1022 SoC requires extra mapping of the memory via MCDI.
Signed-off-by: Viacheslav Galaktionov <viacheslav.galaktionov@oktetlabs.ru>
Signed-off-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Reviewed-by: Ivan Malov <ivan.malov@oktetlabs.ru>
The current approach detects the proxy port on each port (re-)plug and
may spam the log with error messages if the PMD does not support flows.
As testpmd is a debug tool, it must not do such implicit port handling.
Instead, the new API should be called only when the user requests that.
Revoke the existing code. Implement an explicit command-line primitive
to let the user find the proxy port themselves. Provide relevant hints.
Fixes: 1179f05cc9 ("ethdev: query proxy port to manage transfer flows")
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
Currently the vector and simple xmit algorithm don't support multi_segs,
so if Tx offload support MBUF_FAST_FREE, driver could invoke
rte_mempool_put_bulk() to free Tx mbufs in this situation.
In the testpmd single core MAC forwarding scenario, the performance is
improved by 8% at 64B on Kunpeng920 platform.
Cc: stable@dpdk.org
Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
The ice DCF device reset has been supported. Release notes is updated
to synchronize with the feature.
Fixes: 1a86f4dbdf ("net/ice: support DCF device reset")
Signed-off-by: Dapeng Yu <dapengx.yu@intel.com>
Acked-by: Qi Zhang <qi.z.zhang@intel.com>
Update public macros to have RTE_IP_FRAG_ prefix.
Update DPDK components to use new names.
Keep obsolete macro for compatibility reasons.
Renamed experimental function ``rte_frag_table_del_expired_entries``to
``rte_ip_frag_table_del_expired_entries`` to comply with other public
API naming convention.
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Meson 0.58 and above cannot build DPDK on Windows with clang.
Recommend the latest known working version
and warn about the issue and the affected versions.
Suggested-by: Thomas Monjalon <thomas@monjalon.net>
Signed-off-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
This is the CUDA implementation of the gpudev library.
Functionalities implemented through CUDA Driver API are:
- Device probe and remove
- Manage device memory allocations
- Register/unregister external CPU memory in the device memory area
Signed-off-by: Elena Agostini <eagostini@nvidia.com>
The 'IPv4' in the comment is to mark the code snippet, while it made
some confusion. Then removing 'IPv4' description will be clearer.
Fixes: 9a212dc06c ("doc: use code snippets in sample app guides")
Signed-off-by: Joyce Kong <joyce.kong@arm.com>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
Reviewed-by: Conor Walsh <conor.walsh@intel.com>
Starting from FW version xx.32.0108. version, the BlueField 2 and
ConnectX-6 Dx adapters support crypto operations.
Add them to the supported PCI devices list.
Signed-off-by: Raja Zidane <rzidane@nvidia.com>
Acked-by: Matan Azrad <matan@nvidia.com>
Acked-by: Tal Shnaiderman <talshn@nvidia.com>
Replace RTE_EVENT_DEV_CAP_REQUIRES_MAINT, which signaled the need
for the application to call rte_event_maintain(), with
RTE_EVENT_DEV_CAP_MAINTENANCE_FREE, which does the opposite (i.e.,
signifies that the event device does not require maintenance).
This approach is more in line with how other eventdev hardware and/or
software limitations are handled in the Eventdev API.
Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
The --meter section used wrong indentation previously.
Fixes: 6a2cf58a04 ("app/flow-perf: support meter action")
Cc: stable@dpdk.org
Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
Acked-by: Wisam Jaddo <wisamm@nvidia.com>
The flow perf application uses the srtcm_rfc2697 as meter profile
while doing the meter testing.
This patch adds new configuration parameter '--packet-mode' to
generate the meter flows with packet cir instead of byte cir.
Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
Acked-by: Wisam Jaddo <wisamm@nvidia.com>
Change meter-cir option to meter-profile to cover user input for CIR,
CBS & EBS values.
The usage is as below:
--meter-profile=N1,N2,N3 default value is 1250000 156250 0.
Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
Acked-by: Wisam Jaddo <wisamm@nvidia.com>
Add option "policy-mtr" to indicate if meter creation will include policy
or not. Meter creation will keep unchanged without it.
With "policy-mtr", the policy is introduced. API create_meter_policy
is to create a policy. API create_meter_rule will use it to create
a meter. The value of it is used to specify meter policy actions.
Signed-off-by: Haifei Luo <haifeil@nvidia.com>
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
Acked-by: Wisam Jaddo <wisamm@nvidia.com>
Add support for Address Sanitizer (ASan) for PPC/POWER architecture.
Signed-off-by: David Christensen <drc@linux.vnet.ibm.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
The l3fwd example should use the reserved IPv4/v6 reserved address
ranges defined in RFC5735, RFC5180 and RFC863 discard protocol for
the port number in the exact match mode of L3 forwarding.
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Increase the number of routes from 8 to 16 that are statically added for
lpm and em mode as most of the SoCs support more than 8 interfaces.
The number of routes added is equal to the number of ethernet devices
ports enabled through port mask.
Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
Reviewed-by: Conor Walsh <conor.walsh@intel.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Remove the szedata2 device driver as the platform is no longer
supported.
Signed-off-by: Martin Spinler <spinler@cesnet.cz>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
The ConnectX NIC series hardware provides only 63-bit
wide timestamps. The imposed limitations description
added to documentation.
At the moment there are no affected applications known
or bug reports neither, this is just the declaration
of limitation.
Cc: stable@dpdk.org
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@nvidia.com>
This patch defines ASAN_SHADOW_OFFSET for arm64 according to the ASan
documentation. This offset should cover all arm64 VMAs supported by
ASan.
Signed-off-by: Volodymyr Fialko <vfialko@marvell.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Ruifeng Wang <ruifeng.wang@arm.com>
The DPAA DMA driver is an implementation of the dmadev APIs,
that provide means to initiate a DMA transaction from CPU.
The initiated DMA is performed without CPU being involved
in the actual DMA transaction. This is achieved via using
the QDMA controller of DPAA SoC.
Signed-off-by: Gagandeep Singh <g.singh@nxp.com>
Increase default value for config parameter RTE_LIBRTE_IP_FRAG_MAX_FRAG
from 4 to 8. This parameter controls maximum number of fragments per
packet in ip reassembly table. Increasing this value from 4 to 8 will
allow users to cover common case with jumbo packet size of 9KB and
fragments with default frame size (1500B).
As RTE_LIBRTE_IP_FRAG_MAX_FRAG is used in definition of public
structure (struct rte_ip_frag_death_row), this is an ABI change.
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
These actions map to MAE action DECR_IP_TTL. It affects
the outermost header in the current processing state of
the packet, which might have been decapsulated by prior
action DECAP. It also updates IPv4 checksum accordingly.
Signed-off-by: Ivan Malov <ivan.malov@oktetlabs.ru>
Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Reviewed-by: Andy Moreton <amoreton@xilinx.com>
In heterogeneous computing system, processing is not only in the CPU.
Some tasks can be delegated to devices working in parallel.
When mixing network activity with task processing there may be the need
to put in communication the CPU with the device in order to synchronize
operations.
An example could be a receive-and-process application
where CPU is responsible for receiving packets in multiple mbufs
and the GPU is responsible for processing the content of those packets.
The purpose of this list is to provide a buffer in CPU memory visible
from the GPU that can be treated as a circular buffer
to let the CPU provide fondamental info of received packets to the GPU.
A possible use-case is described below.
CPU:
- Trigger some task on the GPU
- in a loop:
- receive a number of packets
- provide packets info to the GPU
GPU:
- Do some pre-processing
- Wait to receive a new set of packet to be processed
Layout of a communication list would be:
-------
| 0 | => pkt_list
| status |
| #pkts |
-------
| 1 | => pkt_list
| status |
| #pkts |
-------
| 2 | => pkt_list
| status |
| #pkts |
-------
| .... | => pkt_list
-------
Signed-off-by: Elena Agostini <eagostini@nvidia.com>
In heterogeneous computing system, processing is not only in the CPU.
Some tasks can be delegated to devices working in parallel.
When mixing network activity with task processing there may be the need
to put in communication the CPU with the device in order to synchronize
operations.
The purpose of this flag is to allow the CPU and the GPU to
exchange ACKs. A possible use-case is described below.
CPU:
- Trigger some task on the GPU
- Prepare some data
- Signal to the GPU the data is ready updating the communication flag
GPU:
- Do some pre-processing
- Wait for more data from the CPU polling on the communication flag
- Consume the data prepared by the CPU
Signed-off-by: Elena Agostini <eagostini@nvidia.com>
Add a function for the application to ensure the coherency
of the writes executed by another device into the GPU memory.
Signed-off-by: Elena Agostini <eagostini@nvidia.com>
In heterogeneous computing system, processing is not only in the CPU.
Some tasks can be delegated to devices working in parallel.
Such workload distribution can be achieved by sharing some memory.
As a first step, the features are focused on memory management.
A function allows to allocate memory inside the device,
or in the main (CPU) memory while making it visible for the device.
This memory may be used to save packets or for synchronization data.
The next step should focus on GPU processing task control.
Signed-off-by: Elena Agostini <eagostini@nvidia.com>
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
The computing device may operate in some isolated contexts.
Memory and processing are isolated in a silo represented by
a child device.
The context is provided as an opaque by the caller of
rte_gpu_add_child().
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
