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 7A113A04C3; Fri, 22 Nov 2019 15:36:32 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2886F235; Fri, 22 Nov 2019 15:36:31 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 2679791 for ; Fri, 22 Nov 2019 15:36:30 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7AF542378F; Fri, 22 Nov 2019 09:36:29 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 22 Nov 2019 09:36:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=+uAznyQXD3mMRNW2bgKluR81cqdfIQTwtAJCflgYXRA=; b=sCGk52ezwaEC hEC7wl5O+lnDdy05/ji76bD0QBdrOxkchSfXPzrJrhheKbaIRtl92kN7XHPCGVMX TSkXUnjrxBr6fsyILl0KEl/F5NBfp6aB5qHPTp1HbyFbI++EixC+0onfgufXelgs c6P369gEYWijYqIzBN7a+xVffOGUCGY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=+uAznyQXD3mMRNW2bgKluR81cqdfIQTwtAJCflgYX RA=; b=a8vQxXsk75eh2uqqSIwaX+b7O9Ct5ysBq9jPrs9yHjyJWkk/YZ+K5OC6H aJC7MaY1yi4Wb8AdwwguO5j2kY2TP41DsA1cJxbXadQnAgAuGow6lPTYS2xiEx4e xCKPrKT3UqnqzfXVKehPvfsa2ZKDQUM5Z+kXkvcDNGgRB6fiPt6jWXvJkdV7R5Xf qC0htUa+cAg1bXZL/otYlUlVqtHrTEmklX8ovI6Iyo+111ofDTWJ4Ikwt4+CrLlE rFUYgTBwLZ0t+lvNqvNMQfIGcujnDlucw5ACAA8WrHiE8ZPSy+CB3n73CH8GOzzp 70zOozMMMpCnCk1jN2Ta3hg/m1H/A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehgedgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpeguphgukhdrohhrghenucfkphepjeejrddufeegrddvtdefrddukeegnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id AF10780059; Fri, 22 Nov 2019 09:36:27 -0500 (EST) From: Thomas Monjalon To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet Cc: david.marchand@redhat.com, ferruh.yigit@intel.com, dev@dpdk.org Date: Fri, 22 Nov 2019 15:36:26 +0100 Message-ID: <3840872.ZpSsLEusID@xps> In-Reply-To: <20191122140347.GE28445@bidouze.6wind.com> References: <785dc5f5-8378-3506-aaa8-39ec22a3eb11@intel.com> <20191122134808.7639-1-thomas@monjalon.net> <20191122140347.GE28445@bidouze.6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [PATCH] devtools: disable automatic probing in null testing 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" 22/11/2019 15:03, Ga=EBtan Rivet: > Hi Thomas, >=20 > On Fri, Nov 22, 2019 at 02:48:08PM +0100, Thomas Monjalon wrote: > > The script test-null.sh is supposed to do a quick and simple > > run of testpmd with null PMD only, for sanity check. > > As it is not supposed to test probing of any other PMD, > > physical device probing is switched to whitelist mode > > by using a fake PCI address (0:0.0). > > It will also help to keep memory usage stable across platforms. > >=20 >=20 > With https://patchwork.dpdk.org/patch/62014/, --manual-probe could be > used as a more standard way of workarounding the PCI bus. I really would like we have a better bus API before implementing some new command line options. Command line options should be optional and considered only helpers for internal applications. Anyway it is another discussion, and I hope I will have time and courage to participate in such rework soon. > This is a common issue, we should have cleaner way of addressing it than > using hacks relying on the PCI bus not panicking up upon finding an > inexistant address. Which is a questionable behavior, users should not > be encouraged to rely on it. Yes