Hello Stephen, On Sat, Jan 4, 2020 at 2:34 AM Stephen Hemminger <step...@networkplumber.org> wrote: > > Recently started using valgrind with DPDK, and the results > are not clean. > > The DPDK has a function that applications can use to tell it > to cleanup resources on shutdown (rte_eal_cleanup). But the > current coverage of that API is spotty. Many internal parts of > DPDK leave files and allocated memory behind. > > This patch set is a start at getting the sub-parts of > DPDK to cleanup after themselves. These are the easier ones, > the harder and more critical ones are in the drivers > and the memory subsystem. > > There are no visible API or ABI changes here.
Could you share what you did to run a dpdk application with valgrind? I tried with testpmd and a 3.15 valgrind (fc30), but I get an init failure on the cpu flags. $ LD_LIBRARY_PATH=/home/dmarchan/builds/build-gcc-shared/install/usr/local/lib64 valgrind /home/dmarchan/builds/build-gcc-shared/install/usr/local/bin/dpdk-testpmd -c 3 --no-huge -m 20 -d librte_mempool_ring.so -d librte_pmd_null.so -w 0:0.0 --vdev net_null1 --vdev net_null2 -- --no-mlockall --total-num-mbufs=2048 -ia ==10258== Memcheck, a memory error detector ==10258== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==10258== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==10258== Command: /home/dmarchan/builds/build-gcc-shared/install/usr/local/bin/dpdk-testpmd -c 3 --no-huge -m 20 -d librte_mempool_ring.so -d librte_pmd_null.so -w 0:0.0 --vdev net_null1 --vdev net_null2 -- --no-mlockall --total-num-mbufs=2048 -ia ==10258== ERROR: This system does not support "RDSEED". Please check that RTE_MACHINE is set correctly. EAL: FATAL: unsupported cpu type. EAL: unsupported cpu type. EAL: Error - exiting with code: 1 Cause: Cannot init EAL: Operation not supported ==10258== ==10258== HEAP SUMMARY: ==10258== in use at exit: 1,388 bytes in 49 blocks ==10258== total heap usage: 97 allocs, 48 frees, 89,426 bytes allocated ==10258== ==10258== LEAK SUMMARY: ==10258== definitely lost: 0 bytes in 0 blocks ==10258== indirectly lost: 0 bytes in 0 blocks ==10258== possibly lost: 0 bytes in 0 blocks ==10258== still reachable: 1,388 bytes in 49 blocks ==10258== suppressed: 0 bytes in 0 blocks ==10258== Rerun with --leak-check=full to see details of leaked memory ==10258== ==10258== For lists of detected and suppressed errors, rerun with: -s ==10258== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Thanks. -- David Marchand
