Remove patch to block debug_autotest since it's no longer
necessary

It fails in the repro builds

Dpdk likes its memory on the same numa node where the nics are
connected. When allocating hugepages using the central point or the
kernel commandline, they will be spread evenly across the numa nodes.
Which could lead to having to allocate double what you actually want
only to make sure a certain numa node gets what you really wanted.

This patch allows users to provide a space separated string when they
actually want to control allocations per node. It uses the same
variables and is backward compatible.

Signed-off-by: Henning Schild <henning.schild@siemens.com>

The scripts might not solve all hugepages related problems and users
might have other allocation mechanisms in place. In fact that is even
suggested in the comments of the config file, should setups become more
complex.

In such complex setups it might not always be correct to reduce the
number of hugepages. So create a way to control that and keep the old
default.

Signed-off-by: Henning Schild <henning.schild@siemens.com>

Gbp-Dch: ignore

Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>

Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>

Update to upstream version '19.11.6'
with Debian dir 15eabe4c5c3e30e930c7906c075cba988dcc57ae

Gbp-Dch: ignore

Gbp-Dch: ignore

Update to upstream version '20.11'
with Debian dir a50c15891895422afe37b5a9297e204058798cac

Gbp-Dch: ignore

Signed-off-by: Thomas Monjalon <thomas@monjalon.net>

The configuration related to the MTU is complex
and have some design issues.
This area should be redesigned a bit.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Matan Azrad <matan@nvidia.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>

Proposing to replace protocol header fields in the ``rte_flow_item_*``
structures with the protocol structs.

This is both for documenting the intention and to be sure
``rte_flow_item_*`` always starts with complete protocol header.

Change will be done in two steps, at first step in v21.02 release,
protocol header struct will be added as union, for example:

Current ``struct rte_flow_item_eth``,

struct rte_flow_item_eth {
	struct rte_ether_addr dst;
	struct rte_ether_addr src;
	rte_be16_t type;
	uint32_t has_vlan:1;
	uint32_t reserved:31;
}

will become in v21.02:

__extension__
struct rte_flow_item_eth {
	union {
		struct {
			struct rte_ether_addr dst;
			struct rte_ether_addr src;
			rte_be16_t type;
		};
		struct rte_ether_hdr hdr;
	};
	uint32_t has_vlan:1;
	uint32_t reserved:31;
}

After this point usage should switch to 'hdr' struct.

And in the second step, in the v21.11 LTS release the protocol fields
will be removed, and the struct will become:

struct rte_flow_item_eth {
	struct rte_ether_hdr hdr;
	uint32_t has_vlan:1;
	uint32_t reserved:31;
}

Already many ``rte_flow_item_*`` structures implemented to have protocol
struct, target is convert all to this usage.

Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>

A new generic shared actions API may be used to create shared
counter. There is no point to keep duplicate COUNT action specific
capability to create shared counters.

Signed-off-by: Andrew Rybchenko <arybchenko@solarflare.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>

PMD can support vector mode when jumbo is enabled as long as MTU is not
large enough to require scattered RX (which also depends on the mbuf size).

Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>

There are common problems with VFIO that get asked over and over on the
mailing list. Document common problems with VFIO and how to fix them or
at least figure out what went wrong.

Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Kevin Traynor <ktraynor@redhat.com>

Currently, we have no documentation on how to use VFIO in no-IOMMU mode.
Add such documentation.

Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Make sure that we always prioritize VFIO over UIO. Also, minor wording
corrections and improvements.

Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>

Currently, the Linux GSG mentions UIO drivers first. This is not ideal
as for the longest time, the recommended way to use DPDK with hardware
devices has been to use VFIO driver.

This commit simply moves UIO section after VFIO, with minor edits.

Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit@intel.com>

This old script relied on deprecated stuff, and especially make.
It also applied some scary 666 permissions on files under /dev/vfio.

Its deprecation had been notified in a previous release, remove it.

Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>

GCC build with '-O0' failed for:
 ../drivers/net/igc/base/igc_api.c
 Assembler messages:
29: Error: selected processor does not support `casp x0,x1,x2,x3,[x4]'
82: Error: selected processor does not support `caspa x0,x1,x2,x3,[x4]'
135: Error: selected processor does not support `caspl x0,x1,x2,x3,[x4]'
188: Error: selected processor does not support `caspal x0,x1,x2,x3,[x4]'

This is due to c_args not been passed to meson.

Fixes: 8cb7c57d

 ("net/igc: support device initialization")
Cc: stable@dpdk.org

Reported-by: Feifei Wang <feifei.wang2@arm.com>
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
Tested-by: Jerin Jacob <jerinj@marvell.com>
Acked-by: Haiyue Wang <haiyue.wang@intel.com>

GCC build with '-O0' on platforms with RTE_ARM_FEATURE_ATOMICS set
failed for:
 ../lib/librte_efd/rte_efd.c
 Assembler messages:
3866: Error: selected processor does not support `crc32cb w0,w0,w1'
3890: Error: selected processor does not support `crc32ch w0,w0,w1'
3914: Error: selected processor does not support `crc32cw w0,w0,w1'
3938: Error: selected processor does not support `crc32cx w0,w0,x1'

This was caused by an architecture specifier added for Clang.
Unlike Clang, GCC considers each inline assembly block to be dependent
and therefore, the architecture specifier impacts assemble of some
blocks require certain extension support.

Removed the architecture for GCC to fix the issue.

Fixes: 8fce34cd

 ("eal/arm: fix clang build of native target")
Cc: stable@dpdk.org

Reported-by: Feifei Wang <feifei.wang2@arm.com>
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
Acked-by: Jerin Jacob <jerinj@marvell.com>

Current information regarding hugepage usage is a little out of date.
Update it to include information on in-memory mode, as well as on
default mountpoints provided by systemd.

Cc: stable@dpdk.org

Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>