Re: rte_bus_probe() does not exit on error

[Thomas Monjalon <thomas@monjalon.net>]

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