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 28F0B42D5C; Mon, 26 Jun 2023 18:13:04 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A9D7840223; Mon, 26 Jun 2023 18:13:03 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id A854E4013F for ; Mon, 26 Jun 2023 18:13:01 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 32FB53200957; Mon, 26 Jun 2023 12:12:59 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute1.internal (MEProxy); Mon, 26 Jun 2023 12:12:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=u256.net; h=cc :cc: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=fm3; t=1687795978; x=1687882378; bh=qc oM/lSPVHvb9tBh3L9BZwZOkKA2OObNfRRqwjAb8MA=; b=jmBJpPbvl7E+4IBUgr Ciu36D0IceALF6wC1kXEgi+oQfgSQJ7t0Sf1miH4vTKpqXjbSh0Fg3r4ylWMrdlp 5bUkdOYLdf6SfbtWQW3pLPSsJdPeiONFOS43+J+dstMGkONCe9Cuyrb+IHeO6sid mXKLxHQTNngZWNiWAL9UZBhHw0syNmvysfkLYihUliM8fZv1k8K/jGGvn8WIGVRO 8/USKGX0qXNWHQXCpWLEau8l7cfnt7p0zX66ZN4cNws4yJUay1jw2CVTyQOWpI93 CrHboguobOxn6anfSz1Fx+zKSqMtAu94LzQ3m/COwaZxNUosLKJiJCwYstVgd+zb nR1Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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=1687795978; x=1687882378; bh=qcoM/lSPVHvb9 tBh3L9BZwZOkKA2OObNfRRqwjAb8MA=; b=eBfZBMiMmmnhlV63Efguhe3iz5F2Y 14VTv1D1mcJezH9dMm6QC9+pMHWi5uj4tol1qilu/DMqpi4K2wcugNW4Ilnx3jEj /fB1mdoMA5zwf3TIAOt703+2YWDBm5F6BbGqbh4TMADs/fIeb4hdkZFuKaf1hWmJ g9PwnK8Lae4f54LOd2Jjzobpk+BzcFdkbjFqAneaEPg2rOaZwp1AUkiZJmM/a2Fj 6i4YGscW6qBRuXZMULpM2L0IfeE4RFyH+AIMAhuMc3y6eP7DmXalN0o2ddRgfwVa NjxjEys2LkBRViPiPRhXydZtP1egJa4PsZ8W625QZTXYAQX9cZt847eHQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgeehfedgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderreejnecuhfhrohhmpefirgot thgrnhcutfhivhgvthcuoehgrhhivhgvsehuvdehiedrnhgvtheqnecuggftrfgrthhtvg hrnhepheffleekhfeivdeitddtffetleduudfgtddtteetkeehkedvueeuvdejtdetvddu necuffhomhgrihhnpeguphgukhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehgrhhivhgvsehuvdehiedrnhgvth X-ME-Proxy: Feedback-ID: ib851476b:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 79FFD31A0064; Mon, 26 Jun 2023 12:12:58 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-499-gf27bbf33e2-fm-20230619.001-gf27bbf33 Mime-Version: 1.0 Message-Id: In-Reply-To: <20230614120428.34dc0320@hermes.local> References: <3825f1afeebd62b3e50535574ddedadb31435616.1579772895.git.grive@u256.net> <20230614120428.34dc0320@hermes.local> Date: Mon, 26 Jun 2023 18:12:20 +0200 From: =?UTF-8?Q?Ga=C3=ABtan_Rivet?= To: "Stephen Hemminger" Cc: dev@dpdk.org, "Vamsi Attunuru" , "Jerin Jacob" Subject: Re: [dpdk-dev] [PATCH v7] eal: add manual probing option Content-Type: text/plain 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 On Wed, Jun 14, 2023, at 21:33, Stephen Hemminger wrote: > On Thu, 23 Jan 2020 10:58:13 +0100 > Gaetan Rivet wrote: > >> Add a new EAL option enabling manual probing in the EAL. >> This command line option will configure the EAL so that buses >> will not trigger their probe step on their own. >> >> Applications are then expected to hotplug devices as they see fit. >> >> Devices declared on the command line by the user (using -w and --vdev), >> will be probed using the hotplug API, in the order they are declared. >> >> This has the effect of offering a way for users to control probe order >> of their devices, for drivers requiring it. >> >> Signed-off-by: Gaetan Rivet >> Acked-by : Vamsi Attunuru >> Tested-by: Vamsi Attunuru >> Reviewed-by: Jerin Jacob >> --- >> >> haven't heard many opinions on the matter, please shout if you see an issue >> with this approach. >> >> @Slava: I have tested rather quickly that it does not break anything, >> and that it works as intended for basic cases. >> Can you test it further for your use-case and tell me if it works fine? >> >> Beyond the obvious difference between both probe mode, something to keep in mind: >> while using -w on invalid devices would not block (PCI) bus probing, it will stop manual >> probing in its track. All devices need to exist and be valid device IDs. >> >> v2: fixed a few typos, map file (and used Travis to validate). >> >> Slava, are you able to test this patch? >> >> v3: properly fixed the map file (inherited 19.08 instead of 19.05). >> >> Added a function to set the probe manual from the application, >> without having the user do it from the command line. >> >> Stopped spamming Slava about it, Vamsi was actually the one interested in it! >> >> Standing issue worth chiming in: >> >> Currently manual-probe will cut off probing from all buses. >> It could be interesting to be able to only cut buses supporting hotplug, >> given that they are the one able to probe devices afterward. >> >> No real use-case for this right now, so leaving as-is. Might be worth >> considering in the future. >> >> v4: Rebased on master, >> Moved implementation in common EAL, >> Used public API within the EAL to set the option, >> Made the API experimental >> >> v5: added note in the Getting Started Guide. >> >> v6: Rebased on master >> >> see http://mails.dpdk.org/archives/dev/2020-January/154178.html >> for reference to this version, linking v7 to v5 thread. >> >> v7: Updated author and SoB. >> >> doc/guides/linux_gsg/eal_args.include.rst | 13 ++++++ >> doc/guides/rel_notes/release_20_02.rst | 9 ++++ >> lib/librte_eal/common/eal_common_bus.c | 6 +++ >> lib/librte_eal/common/eal_common_dev.c | 54 ++++++++++++++++++++++ >> lib/librte_eal/common/eal_common_options.c | 8 ++++ >> lib/librte_eal/common/eal_internal_cfg.h | 1 + >> lib/librte_eal/common/eal_options.h | 2 + >> lib/librte_eal/common/eal_private.h | 9 ++++ >> lib/librte_eal/common/include/rte_eal.h | 36 +++++++++++++++ >> lib/librte_eal/rte_eal_version.map | 4 ++ >> 10 files changed, 142 insertions(+) > > This patch seems to have been held in limbo for 3 years. > > For me, it is ok, but concerned that it opens up a whole scenario of possible > usages that may not be tested, and probably don't work. Testing all the possible > combinations of probe ordering is a geometric problem. > > So if user submits bug then the response would have to be: > Manual probing is an experimental option which may not work. Hello Stephen, I am not pushing for this series anymore. I wrote it to help other people, I guess they used another way since. If someone needs it, I can take a moment to reanimate it. I'm still using the PCI bus hack to force manual probing, as well as port hotplug to control strict ordering. I guess at this point this is the stable way of working with DPDK, instead of a proper documented option. Best regards, -- Gaetan Rivet