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 156A0A0093; Tue, 3 May 2022 11:52:42 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ADA3340C35; Tue, 3 May 2022 11:52:41 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 2262440691 for ; Tue, 3 May 2022 11:52:40 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id 3894D20EAB83; Tue, 3 May 2022 02:52:39 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 3894D20EAB83 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1651571559; bh=k2KSBWPFdvQcfmfb1kehYQS7OywLlv0fn+7/ZThZ6xQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UqdFzKnjJBkSvRYZMuZXhlqaji3pygU866Fz0XXWpYGGTMMKzhOdw9pVlFgTJjP2e 9KXJnewsUVJ3EgolpXOe/dbBZnAT5ddoyzhFE2peklRqOne65qrX16inYJmp9rB3mS AMaZgtxtfGQnQyKinzYgdA3HO6eTiuQnGsXwwovg= Date: Tue, 3 May 2022 02:52:39 -0700 From: Tyler Retzlaff To: Thomas Monjalon 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 Message-ID: <20220503095239.GB5181@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <10320642.NyiUUSuA9g@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10320642.NyiUUSuA9g@thomas> User-Agent: Mutt/1.5.21 (2010-09-15) 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 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. 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.