From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C2D1C433FF for ; Thu, 1 Aug 2019 13:26:47 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id ED7D22064A for ; Thu, 1 Aug 2019 13:26:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ED7D22064A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4CFC01C1EF; Thu, 1 Aug 2019 15:26:46 +0200 (CEST) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by dpdk.org (Postfix) with ESMTP id 33C921C1ED for ; Thu, 1 Aug 2019 15:26:45 +0200 (CEST) Received: by mail-io1-f65.google.com with SMTP id h6so19083371iom.7 for ; Thu, 01 Aug 2019 06:26:45 -0700 (PDT) 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:content-transfer-encoding; bh=Dk3jZGxxOvAYVi+bbV8OFZ0yLgKbWnr0lOAllpoaU74=; b=D5ooUiEMmy6l3rAOwCjkQg7Wo4ihA9SNZ5HFd0T0SubL7GIeE9GZJBv9bn2JXbeTht n4tSqJ0RceORU5ecTbuKiT58PIiZpTgOOpEhd7rBbSp9jDwJ/j2CnxvajP2EPSFHXYby H0pPiTppzrdtt9BXhB1ogZcChpPP9Vm/bwbxncDIRIVqVkDc9Ttc34ogQCudkqSCr3HC braY553Rn5ZQuijn8NLDr91FHTbR9vK0folZN64i5RkNyGXwmVwCc3QeDvl2xB7bFmwn T7dNJ4HVXI1UwRNzL4k2+Pd0365SCKGl5UagVdct9GJA9dANAR4NIG/bKEIYxgrNUoMJ GqZg== X-Gm-Message-State: APjAAAUywIO4QNgptmGc9qNxEqMWqxr8EgUDS2Ogu5G58/MtM8ZcSaBY GcZwwilwKPy79yvP40l9j5d1G20YsZP+hJEat3DsBg== X-Google-Smtp-Source: APXvYqzbW45mJwCkRTvYLHjc/4kI9xqWmWFFz0pk2iPZOA+fdtPFZO0pO9HgOc/QObcw6wq4AYAbgIV9krmst1YvzHg= X-Received: by 2002:a5e:9917:: with SMTP id t23mr49305454ioj.23.1564666004572; Thu, 01 Aug 2019 06:26:44 -0700 (PDT) MIME-Version: 1.0 References: <1564662465-2925-1-git-send-email-david.marchand@redhat.com> <20190801132201.ty75yrktxep6ei3k@bidouze.vm.6wind.com> In-Reply-To: From: David Marchand Date: Thu, 1 Aug 2019 15:26:33 +0200 Message-ID: To: =?UTF-8?Q?Ga=C3=ABtan_Rivet?= Cc: dev , Aaron Conole , Michael Santana Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] test/eal: do not scan PCI devices for memory tests 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 Thu, Aug 1, 2019 at 3:24 PM David Marchand w= rote: > > Hey Ga=C3=ABtan, > > On Thu, Aug 1, 2019 at 3:22 PM Ga=C3=ABtan Rivet = wrote: > > > > On Thu, Aug 01, 2019 at 02:29:21PM +0200, David Marchand wrote: > > > On Thu, Aug 1, 2019 at 2:28 PM David Marchand wrote: > > > > > > > > The memory tests currently check that, for normal mode (not legacy = mode), > > > > there is no memory left behind when exiting. > > > > > > > > The problem is that if a ethdev port is allocated when scanning pci > > > > devices (even if the driver probe fails like when you have a virtio > > > > management interface attached to the kernel), on exit, dpdk won't f= ree > > > > the associated memory since ethdev never frees the ethdev memzone. > > > > > > > > Workaround this by disabling pci scan. > > > > > > Not entirely happy with this patch. > > > I am open to suggestions :-) > > > > >> Why not cleanup on .fini the ethdev subsystem? > > I had this in mind, tried it quickly, but it still failed. > So I suppose .fini is executed after rte_eal_cleanup (where the > freeing of the hugepages happens). Or we move rte_eal_cleanup in a .fini and play with priorities... too dangerous for 19.08, from my pov. --=20 David Marchand