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 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 1DBF5C433FF for ; Fri, 2 Aug 2019 13:45:36 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id D6A6220679 for ; Fri, 2 Aug 2019 13:45:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D6A6220679 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 3D5B91C2B0; Fri, 2 Aug 2019 15:45:35 +0200 (CEST) Received: from mail-vk1-f193.google.com (mail-vk1-f193.google.com [209.85.221.193]) by dpdk.org (Postfix) with ESMTP id 64D151C29F for ; Fri, 2 Aug 2019 15:45:34 +0200 (CEST) Received: by mail-vk1-f193.google.com with SMTP id b69so15370251vkb.3 for ; Fri, 02 Aug 2019 06:45:34 -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; bh=wdCLxTAfaoOO7vQzSsWy6heuphbsfurd8RrlVVtoL3k=; b=AUrWlRKi0PLAO4PAn2C8I7an1B1jPcWxAUeZtWsyiRUtE1s/X63fyVO2iRrfVl9z9k SIWHbZj7ekSce82njU96EozhnNWKpGE8qtMMV891U38/Z9Whki5NXpR/SWddBurZLLT2 y3Uk7evHA6HQsCLIYC6s85Xoqyomq4ttsNC6K7WshuwHkrifBSUQKf5R58LwYwoBRa23 IMKxyzsCh4RWS9E8eDFFcRGGgyLz9OsSnH/nRrY4WpyUvme15eWnGzUkUuPI/bMOfBee l6nMGHYGSqShSCacy9PsfIAw3jH0ZDyvVJDxCkpXZ0Og8iB58CJTTKKf0MbakNfWcWga UGqQ== X-Gm-Message-State: APjAAAXEQQD3RnGd0qtIdEtANPRkq2srZd14Bt3EY/U1FKWRzRUjAGCd SEb0vVWBrQILRGYNtN9564RRZVUiCAdg3XyajXDb3w== X-Google-Smtp-Source: APXvYqwtNFC7swX/ecb5la+ec6FPJioAFG9AJwKr/uRJMfx9JrncOBoaNmllOaRXM+8jsSx4oHxDlj4ehhMTsUfWDXU= X-Received: by 2002:a1f:50c1:: with SMTP id e184mr53672836vkb.86.1564753533742; Fri, 02 Aug 2019 06:45:33 -0700 (PDT) MIME-Version: 1.0 References: <1564662465-2925-1-git-send-email-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Fri, 2 Aug 2019 15:45:22 +0200 Message-ID: To: Aaron Conole Cc: dev , Michael Santana , dpdk stable , "Burakov, Anatoly" Content-Type: text/plain; charset="UTF-8" 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 Fri, Aug 2, 2019 at 3:37 PM Aaron Conole wrote: > > David Marchand writes: > > > 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 free > >> 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 :-) > > Seems like an order of allocation / free issue. Is it possible to > change the order to be consistent? IE: we only allocate something after > we know there's good reason to do so and then we can be sure to always > free? I don't know the code in this area well enough yet to comment any > more than that. Err, this looks hard to achieve. The test is quite basic, in that it expects all hugepage files to be removed on dpdk exit (meaning all allocations freed). -- David Marchand