On Wed, Feb 5, 2020 at 1:07 PM Stephen Hemminger <step...@networkplumber.org> wrote: > > On Wed, 5 Feb 2020 10:32:49 +0100 > David Marchand <david.march...@redhat.com> wrote: > > > 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) > > > > I am testing with valgrind on ARM. > It should be possible on x86 but you need to dial down the RTE_MACHINE > choice to something valgrind understands. >
Ok, so no black magic in valgrind :-) Yeah I managed to run with the x86-default target we have in test-meson-builds.sh. Thanks. -- David Marchand
