From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E45A6A04FA; Wed, 5 Feb 2020 13:33:04 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0D3411C135; Wed, 5 Feb 2020 13:33:04 +0100 (CET) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 1B4BF1C12C for ; Wed, 5 Feb 2020 13:33:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580905982; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YmCEE3zT4oBk+ugd4O3ETIc44ldgwsSce6IHq5acdDY=; b=NOadxW+WIRTTiZCBcWUTn4vM+XSfFSxkQadnU4H604CEV3zRZt+aQDlVIouGr5TCjXF1nv qaX3C19oVpAuEaxE0QOFkkNIFkuRAuVfIFMi1zO8ARVSWl1yKnw2rqDXcb3X/0TLN3Ru+f vbXWfG/QyEe28fnvhdcDkkZ1ddYrFfQ= Received: from mail-ua1-f69.google.com (mail-ua1-f69.google.com [209.85.222.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-290-Cusy_vsHMkmSDCAkHlhCUA-1; Wed, 05 Feb 2020 07:32:57 -0500 Received: by mail-ua1-f69.google.com with SMTP id h10so522043uab.12 for ; Wed, 05 Feb 2020 04:32:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xjHHDg67zeGi0Czt++OUzR7xtSxYHtJl/lbh8iWuAr4=; b=oseefxv0bzj97SUHYXd2buQW9oAxxpN+0s4biUp4iF8asgDDEvAHGUc7RO9Zbe0qP8 sPnu0E25ZGKtPdcAdnwlThtbe9+O9QoDLtUglBQuVtymgHQABtHPQlX2MgjBKdyw+0+E y3kB59Sw/bcUQh/tZVoo9KcnOl0Dpp0kRwA9RDPdkPDSvGSkXPlFUSgcQj2Sd5x9aDrB A7yX33OgsNKd5ntcP9nYxTV3IUpVHD8ErooNay+xjYKiFCWMK5J88HEaC5lztyCvAXLc QD+NF24PrEM1eUoujYQiq0sFzyeUs2zUAht6qlkuZfrxsbtr1BVPQbMoZ2vnwCBtHkKa GY4g== X-Gm-Message-State: APjAAAVS+RtM1R8bfv5RVp3tsToooNWakYa2KPg1J+fJemIbGbvlzFxw yAES3nEKmaIJ5rMtqprGeLZu64CH0fCmAmxJ2kIrOywcRyQftxtC2RCSnNRsmZn9tFIi/70HqK5 t1iTPDWfVQ05Wwq+43e0= X-Received: by 2002:a67:905:: with SMTP id 5mr21294087vsj.105.1580905976472; Wed, 05 Feb 2020 04:32:56 -0800 (PST) X-Google-Smtp-Source: APXvYqwQ+b+VI/+UBs1mCrzPMwNHOVHndsBs1mzL02gcnBKIyrdZ/FvFVwx3vDeZdZkq7+O47mZMCiPLSnmUkQFFAGI= X-Received: by 2002:a67:905:: with SMTP id 5mr21294064vsj.105.1580905975990; Wed, 05 Feb 2020 04:32:55 -0800 (PST) MIME-Version: 1.0 References: <20200104013341.19809-1-stephen@networkplumber.org> <20200205040719.0e429ae8@shemminger-XPS-13-9360> In-Reply-To: <20200205040719.0e429ae8@shemminger-XPS-13-9360> From: David Marchand Date: Wed, 5 Feb 2020 13:32:44 +0100 Message-ID: To: Stephen Hemminger Cc: dev , Luca Boccassi , Bruce Richardson X-MC-Unique: Cusy_vsHMkmSDCAkHlhCUA-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH 00/14] cleanup resources on shutdown X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Feb 5, 2020 at 1:07 PM Stephen Hemminger wrote: > > On Wed, 5 Feb 2020 10:32:49 +0100 > David Marchand wrote: > > > Hello Stephen, > > > > On Sat, Jan 4, 2020 at 2:34 AM Stephen Hemminger > > 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=3D/home/dmarchan/builds/build-gcc-shared/install/usr/= local/lib64 > > valgrind /home/dmarchan/builds/build-gcc-shared/install/usr/local/bin/d= pdk-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=3D2048 -ia > > =3D=3D10258=3D=3D Memcheck, a memory error detector > > =3D=3D10258=3D=3D Copyright (C) 2002-2017, and GNU GPL'd, by Julian Sew= ard et al. > > =3D=3D10258=3D=3D Using Valgrind-3.15.0 and LibVEX; rerun with -h for c= opyright info > > =3D=3D10258=3D=3D Command: > > /home/dmarchan/builds/build-gcc-shared/install/usr/local/bin/dpdk-testp= md > > -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=3D2048 -ia > > =3D=3D10258=3D=3D > > 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 > > =3D=3D10258=3D=3D > > =3D=3D10258=3D=3D HEAP SUMMARY: > > =3D=3D10258=3D=3D in use at exit: 1,388 bytes in 49 blocks > > =3D=3D10258=3D=3D total heap usage: 97 allocs, 48 frees, 89,426 bytes= allocated > > =3D=3D10258=3D=3D > > =3D=3D10258=3D=3D LEAK SUMMARY: > > =3D=3D10258=3D=3D definitely lost: 0 bytes in 0 blocks > > =3D=3D10258=3D=3D indirectly lost: 0 bytes in 0 blocks > > =3D=3D10258=3D=3D possibly lost: 0 bytes in 0 blocks > > =3D=3D10258=3D=3D still reachable: 1,388 bytes in 49 blocks > > =3D=3D10258=3D=3D suppressed: 0 bytes in 0 blocks > > =3D=3D10258=3D=3D Rerun with --leak-check=3Dfull to see details of leak= ed memory > > =3D=3D10258=3D=3D > > =3D=3D10258=3D=3D For lists of detected and suppressed errors, rerun wi= th: -s > > =3D=3D10258=3D=3D 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