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 <tho...@monjalon.net> > Sent: Tuesday, May 3, 2022 5:14 AM > To: Tyler Retzlaff <roret...@linux.microsoft.com> > Cc: McDaniel, Timothy <timothy.mcdan...@intel.com>; dev@dpdk.org; Van > Haaren, Harry <harry.van.haa...@intel.com>; Jerin Jacob > <jer...@marvell.com>; Wires, Kent <kent.wi...@intel.com>; > david.march...@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 >
