RE: rte_bus_probe() does not exit on error

["McDaniel, Timothy" <timothy.mcdaniel@intel.com>]

Thanks for the reply, Thomas.  For us, our request is to terminate if a command
line syntax error is detected.  I understand that this would break backward 
compatibility, so perhaps we can look at addressing the issue  at the next appropriate
release.

Thanks,
Tim


> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Tuesday, May 3, 2022 5:14 AM
> To: Tyler Retzlaff <roretzla@linux.microsoft.com>
> Cc: McDaniel, Timothy <timothy.mcdaniel@intel.com>; dev@dpdk.org; Van
> Haaren, Harry <harry.van.haaren@intel.com>; Jerin Jacob
> <jerinj@marvell.com>; Wires, Kent <kent.wires@intel.com>;
> david.marchand@redhat.com
> Subject: Re: rte_bus_probe() does not exit on error
> 
> 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
>