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 44C2FA0093; Tue, 3 May 2022 12:14:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E098540C35; Tue, 3 May 2022 12:14:29 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id BFD0B40691 for ; Tue, 3 May 2022 12:14:28 +0200 (CEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 35D985C00FB; Tue, 3 May 2022 06:14:28 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 03 May 2022 06:14:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding: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=fm1; t=1651572868; x= 1651659268; bh=6J1KF+J9wTfnuMn8Ga6loy67pRcxLDOqJEa24NjgucM=; b=Y 6NQZohCZRkBOngcJ5DVPZCrtmGHwqebxLw+HJ4wPllwibpTfPc8Gr1Lw6JVirqY8 K6VTUofiERmZy5MNgOeezAbxsEFSadOSKom2ymHvipHOdymBG26MuSzNk+fZdR29 38aStGoXMdy7wn8INRS0Mv/d50uLf8ggVrr0soqHwg6mPyTCatjdSzKpEYjePJj9 Bdy5TR8AdJI7VzleUCBGUpCRljAWSPX2Dcuz0eIvTE7/8WrVhH2IISo0YZYHseK9 5qTH3MBRfTdvWOtHdCuAok4GyNz6onGIPbnk4aTlml6EaO6AZde5PKQmGiK9BfYO snkGIL5IRlrrJCkopSjyQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date: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=fm1; t=1651572868; x=1651659268; bh=6J1KF+J9wTfnu Mn8Ga6loy67pRcxLDOqJEa24NjgucM=; b=Wvef02w2KVPdYm1Etp0+9cB8syT8G w6EMLdpSUdTnWQP0UeoTgD4d61sG4Se5W1kJ3yz5vhmTXEAZFtbTasGZZgLQq8cE GvFuYPOMqZoxwkVSZeNRp5oElshKl2P0jgB5mEtr+ALuTzfKj7k++A3l09VwZ2Cj Oi5Rpg0Cp8JCc71d4OJ+v7P744ngJ7qJO1G/uyoSvyRkPsueMgYN/V4kTkVPlY7N i1fZy3PNjzRnnAlPKyhcAxhu/PYrdXCG1fJCkXs2JMhCCn6dBCx1SLkWrYFpkY0k EatG47KGKZhPn5aKn7vKL2OjBR+ADnFd59F4g+EL7PVmwntFtRqj9F+Cg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdejgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepjeejffffgfffkeefffelgfekleetjeffleeludeghfehleffteeh veduffdugfdvnecuffhomhgrihhnpeguphgukhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhn rdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 3 May 2022 06:14:27 -0400 (EDT) From: Thomas Monjalon To: Tyler Retzlaff Cc: "McDaniel, Timothy" , "dev@dpdk.org" , "Van Haaren, Harry" , Jerin Jacob , "Wires, Kent" , david.marchand@redhat.com Subject: Re: rte_bus_probe() does not exit on error Date: Tue, 03 May 2022 12:14:25 +0200 Message-ID: <4331513.Mh6RI2rZIc@thomas> In-Reply-To: <20220503095239.GB5181@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <10320642.NyiUUSuA9g@thomas> <20220503095239.GB5181@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 03/05/2022 11:52, Tyler Retzlaff: > On Mon, May 02, 2022 at 11:54:29PM +0200, Thomas Monjalon wrote: > > Hello, > > > > 02/05/2022 23:20, McDaniel, Timothy: > > > Hello DPDK community, > > > > > > I am following up on a question/comment that I submitted on April 18, for which > > > I have not received any responses. See the original comment below for context. > > > > > > Are there objections to modifying the behavior of rte_bus_probe() so that it propagates > > > any errors detected while processing the command line arguments? It currently ignores > > > errors and continues on, always returning success instead of any error that was returned > > > by the probe function. > > > > You are suggesting to stop if probing of one device fails. > > I am not sure it is a good idea, because sometimes we are OK > > to proceed even if one device is missing. > > > > We could differentiate a fatal error like parsing syntax, > > and "normal error" of a device which cannot be probed in some conditions. > > a bit of a tangent but it would be nice if eal initialization wasn't > coupled to bus/device enumeration at all and instead there was more > control over bus/device enumeration where the application could choose if > it wants the error to be fatal or not .. after eal was initialized. I agree with the idea. > with it burried inside eal initialization the application has no control > over the policy to fail or not, also there are other peripherial > problems that arise due to the composition e.g. event callbacks can't > be registered until after probe from init has occurred and eal init > is completed. > > it would be a huge compat break (i'm ignoring that) but so would > failing eal init for reasons it does not currently fail. Yes compatibility is a blocker. A better idea would be to not use rte_eal_init() at all. I am convinced we should split this function in multiple parts. It would allow keeping compatibility with the legacy function while allowing more flexibility with new functions. You may be interested by this talk: https://fast.dpdk.org/events/slides/DPDK-2018-09-Default.pdf