[dpdk-dev] [PATCH 00/14] cleanup resources on shutdown

David Marchand david.marchand at redhat.com
Wed Feb 5 13:32:44 CET 2020


On Wed, Feb 5, 2020 at 1:07 PM Stephen Hemminger
<stephen at networkplumber.org> wrote:
>
> On Wed, 5 Feb 2020 10:32:49 +0100
> David Marchand <david.marchand at redhat.com> wrote:
>
> > Hello Stephen,
> >
> > On Sat, Jan 4, 2020 at 2:34 AM Stephen Hemminger
> > <stephen at 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



More information about the dev mailing list