From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 36F174261A; Fri, 22 Sep 2023 14:57:41 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C831B40150; Fri, 22 Sep 2023 14:57:40 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id E32CA4013F for ; Fri, 22 Sep 2023 14:57:38 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F15A15C01DB; Fri, 22 Sep 2023 08:57:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 22 Sep 2023 08:57:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1695387455; x=1695473855; bh=8SsId26KxWG+Mk01TwtOYlC9A2rGXurDc0j dh89Czxo=; b=nDOoGkeCXwKSrpig3AMLBG66SgP2xeG5JXjL95vwArqobyeIcdN 0X0lr0Fq7nnJbDyhNUWuiaVVfvLHf0sTTInilpyLwUrwbcaDBVU8vWyhGlz+oBN7 RwXzwCeJpIcY+siOWL588wmOk9PmbcPobAf7l4DZZuV+47qVnMNZ4sxa6Cds8GfB hmnv6vPrCEpILXv2ikKFrnZSLPMpM377fKFjgnw5VfN53Wz/ruiovby1UtzDpZDb ZAb7ODq7quQUuU1rZqwmdzpr+NqCOdenH1V7ZhR/R/5lEd35q5fh+CN+d0/Dj48c DqH9zUaz+bxqEy4AyKNItifoMaWnUbZch6Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1695387455; x=1695473855; bh=8SsId26KxWG+Mk01TwtOYlC9A2rGXurDc0j dh89Czxo=; b=oQUMZzfTQqdrh+U5t/VF7x7wSDq55SrNMPDuHB+9E7+/QA4naF4 fFc1ZaiYTZjDbWP6EWp/SH69670ExeKE8eWhT3u8q5aiz2cd037pMA28a4qdR2SZ R1PlmzzWM6cylLuzPzK9Xn1cGOgPrW4pqw8MAuYvBmkj+X3M9aK4sBNnIImmyIfI ChswwHW9UBCTW7uSC3HHnm9WXKEOVT5cZeySf8/FPihM0p+QUi38EeIaOxndLGW8 58/6pmUtMlo5MzGF8MIcrd01a1g5GnMnc9grUijEuvZMkJEJFLQ9R2Qew/66ZFvR tmTvvSJMiQt2k4/m2ZmEFuPG19hhokRLaOQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudekkedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpefftdeuhfehvdekleelveffvdelhfelhedvgedtvddvudeuieev tdfgjedvudegfeenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 22 Sep 2023 08:57:34 -0400 (EDT) From: Thomas Monjalon To: David Marchand , Bruce Richardson Cc: dev@dpdk.org, Aaron Conole , Ferruh Yigit Subject: Re: [PATCH 0/1] make file prefix unit test more resilient Date: Fri, 22 Sep 2023 14:57:32 +0200 Message-ID: <11510039.CDJkKcVGEf@thomas> In-Reply-To: References: <20230914104215.71408-1-bruce.richardson@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 20/09/2023 12:09, Bruce Richardson: > On Wed, Sep 20, 2023 at 12:00:08PM +0200, David Marchand wrote: > > On Thu, Sep 14, 2023 at 12:42=E2=80=AFPM Bruce Richardson > > wrote: > > > > > > When examining the IOL testing failures for patch series [1], I obser= ved > > > that the failures reported were in the eal_flags_file_prefix unit tes= t. > > > I was able to reproduce this on my system by passing an additional > > > "--on-pci" flag to the test run, since the log to the test has errors > > > about device availability. Adding the "no-pci" flag to the individual > >=20 > > Something is not clear to me. > >=20 > > While I understand that passing "no-pci" helps avoiding the issue (as > > described below), I have some trouble understanding this passage > > (above) with "--on-pci". >=20 > That's a typo for no-pci. When I ran the test on my system with the main > process using no-pci, I was able to reproduce the issue seen in the IOL > lab. Otherwise I couldn't reproduce it. >=20 > > How did you reproduce the issue? > >=20 > >=20 > > > test commands used by the unit tests fixed the issue thereafter, > > > allowing the test to pass in all cases for me. Therefore, I am > > > submitting this patch in the hopes of making the test more robust, si= nce > > > the observed failures seem unrelated to the original patchset [1] I > > > submitted. > > > > > > [1] http://patches.dpdk.org/project/dpdk/list/?series=3D29406 > > > > > > Bruce Richardson (1): > > > app/test: skip PCI bus scan when testing prefix flags > > > > > > app/test/test_eal_flags.c | 20 ++++++++++---------- > > > 1 file changed, 10 insertions(+), 10 deletions(-) > >=20 > > Iiuc, the problem is that the file_prefix unit test can fail if any > > DPDK subsystem forgets to release some memory and some hugepages are > > left behind at the cleanup step. > > Passing --no-pci as you suggest hides issues coming from PCI drivers. > >=20 > > This is something I tried to fix too, with > > https://patchwork.dpdk.org/project/dpdk/list/?series=3D29288 though my > > fix only handles a part of the issue (here, the ethdev drivers). > >=20 > > Another way to make the file prefix more robust would be to remove the > > check on released memory, or move it to another test. > >=20 > I actually think the test is a good one to have. Also, taking in your pat= ch > to help with the issue is a good idea also. >=20 > I'd still suggest that this patch be considered anyway, as there is no ne= ed > to do PCI bus scanning as part of this test. Therefore I'd view it as a > harmless addition that may help things. I'm hesitating. This test is checking if some memory is left, and I think it is sane. If we add --no-pci, we reduce the coverage of this check. Now that the root cause is fixed by David in ethdev (https://patches.dpdk.org/project/dpdk/patch/20230821085806.3062613-4-david= =2Emarchand@redhat.com/) we could continue checking memory freeing with PCI drivers. So I tend to reject this patch. Other opinions?