Drivers librte_mempool_ring.so and librte_pmd_null.so are loaded by
librte_eal.so when running testpmd.
In Ubuntu Xenial, driver path is installed to RPATH on testpmd. This
allows librte_eal.so to find drivers by using the RPATH.
However, in Ubuntu Bionic, driver path is installed to RUNPATH instead.
The RUNPATH on testpmd is not available by librte_eal.so and therefore
lead to driver load failure:
EAL: Detected 32 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: librte_mempool_ring.so: cannot open shared object file:
No such file or directory
EAL: FATAL: Cannot init plugins
EAL: Cannot init plugins
Add 'drivers' into LD_LIBRARY_PATH so that testpmd can find and make
use of these shared libraries.
Signed-off-by: Ruifeng Wang <ruifeng.wang@arm.com>
Reviewed-by: Gavin Hu <gavin.hu@arm.com>
Acked-by: Aaron Conole <aconole@redhat.com>
Following [1], testpmd memory consumption has skyrocketted.
The rte_port structure has gotten quite fat.
struct rte_port {
[...]
struct rte_eth_rxconf rx_conf[65536]; /* 266280 3145728 */
/* --- cacheline 53312 boundary (3411968 bytes) was 40 bytes ago --- */
struct rte_eth_txconf tx_conf[65536]; /* 3412008 3670016 */
/* --- cacheline 110656 boundary (7081984 bytes) was 40 bytes ago --- */
[...]
/* size: 8654936, cachelines: 135234, members: 31 */
[...]
testpmd handles RTE_MAX_ETHPORTS ports (32 by default) which means that it
needs ~256MB just for this internal representation.
The reason is that a testpmd rte_port (the name is quite confusing, as
it is a local type) maintains configurations for all queues of a port.
But where you would expect testpmd to use RTE_MAX_QUEUES_PER_PORT as the
maximum queue count, the rte_port uses MAX_QUEUE_ID set to 64k.
Prefer the ethdev maximum value.
After this patch:
struct rte_port {
[...]
struct rte_eth_rxconf rx_conf[1025]; /* 8240 49200 */
/* --- cacheline 897 boundary (57408 bytes) was 32 bytes ago --- */
struct rte_eth_txconf tx_conf[1025]; /* 57440 57400 */
/* --- cacheline 1794 boundary (114816 bytes) was 24 bytes ago --- */
[...]
/* size: 139488, cachelines: 2180, members: 31 */
[...]
With this, we can ask for less memory in test-null.sh.
[1]: https://git.dpdk.org/dpdk/commit/?id=436b3a6b6e62
Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
This patch functionally reverts the patch in fixes line to not have any
hardcoded library path in the final binary for the security reasons, in
case this binary distributed to production environment.
RPATH only added in RTE_DEVEL_BUILD case and this binary shouldn't
distributed, but still removing it to be cautious.
Fixes: 8919f73bcb ("mk: add build directory to library search path")
Cc: stable@dpdk.org
Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
The script test-null.sh is supposed to do a quick and simple
run of testpmd with null PMD only, for sanity check.
As it is not supposed to test probing of any other PMD,
physical device probing is switched to whitelist mode
by using a fake PCI address (0:0.0).
It will also help to keep memory usage stable across platforms.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Tested-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: David Marchand <david.marchand@redhat.com>
In order to ease basic testing with customized options,
EAL and testpmd options can be added as third and fourth arguments
of the "null PMD" script.
Also, the first argument becomes more flexible by accepting
the testpmd path as an alternative to the build directory.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
This small testpmd test was not working for a long time
because of several changes in EAL and mempool.
The 3 main issues solved are:
- Make --no-huge working by specifying an amount of memory
to allocate in legacy mode, and disabling mlockall.
- Load a mempool handler in shared library case.
- Support meson
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
The remaining scripts in the scripts/ directory are only useful
to developers. That's why devtools/ is a better name.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Tested-by: Ferruh Yigit <ferruh.yigit@intel.com>
