RE: [RFC v2 5/5] eal: configure initial device probing

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 2 March 2026 10.02
> 
> On Fri, Feb 27, 2026 at 02:10:45PM -0800, Stephen Hemminger wrote:
> > On Fri, 27 Feb 2026 13:51:48 +0000	
> > Bruce Richardson <bruce.richardson@intel.com> wrote:
> >
> > > On Fri, Feb 27, 2026 at 02:43:46PM +0100, Thomas Monjalon wrote:
> > > > 26/02/2026 17:50, Robin Jarry:
> > > > > David Marchand, Feb 26, 2026 at 17:20:
> > > > > > Some applications use port hotplug as their primary way for
> using DPDK
> > > > > > resources.
> > > > > > Having a systematic device probing is a problem when not all
> available
> > > > > > resources will be used by the application, as such
> applications won't set
> > > > > > an explicit allow list at startup.
> > > > > >
> > > > > > This is the case for OVS on systems with multiple mlx5
> devices:
> > > > > > one device can be used by the kernel while the other(s) are
> used by DPDK.
> > > > > > In such a setup, the kernel used device may get reconfigured
> in
> > > > > > unexpected ways and trigger issues like the one described by
> Kevin
> > > > > > not so long ago in bugzilla 1873.
> > > > > >
> > > > > > Add an EAL option so that we can change the default behavior
> from
> > > > > > block-listing to allow-listing.
> > > > [...]
> > > > > > +	const char * const argv29[] = {prgname, prefix, mp_flag,
> eal_debug_logs,
> > > > > > +				       "--allow-explicitly" };
> > > > >
> > > > > I am not convinced by the option name. What do you think of:
> > > > >
> > > > > 	--no-autoprobe
> > > > >
> > > > > That would match the Linux sriov_drivers_autoprobe sysfs.
> > > >
> > > > The name --no-autoprobe is better indeed.
> > > >
> > > > The exact effect of this option is to disable initial probing
> > > > of devices on all buses (except vdev).
> > > > Another name could be --no-initial-probing
> > > >
> > > > I think we should add the opposite option as well
> > > > to allow changing the default mode later.
> > > > For such an option, --autoprobe looks better than --initial-
> probing.
> > > >
> > > > Other opinions?
> > > >
> > > >
> > > > [...]
> > > > > Depending on what option name we settle on, could you add a
> short flag
> > > > > too? E.g.:
> > > > >
> > > > > BOOL_ARG("--no-autoprobe", "-N", "Disable automatic probing of
> non-blocked devices", no_autoprobe)
> > > > >
> > > > > Or:
> > > > >
> > > > > BOOL_ARG("--no-autoprobe", "-P", "Disable automatic probing of
> non-blocked devices", no_autoprobe)
> > > >
> > > > I don't see the benefit of a short flag.
> > > > It makes reading commands less obvious.
> > > >
> > > I actually would prefer to have a short option available, and I'd
> really
> > > like that short option to be "-A" since it serves as the perfect
> addition
> > > to the "-a" flag to specify devices to probe.
> > >
> > > Based on that, I would look for long options which allow "-A" as
> the short
> > > version for example:
> > >
> > > --allowlisted-devs-only
> > >
> > > /Bruce
> >
> > Also if -b or --block-list become a no op with --no-autoprobe. So it
> should be a warning?
> 
> Yes, I think a warning about ignored parameter would be appropriate.
> 
> /Bruce

I haven't been following this discussion, so I might me completely off here.

IIUC, this option is used for specifying which devices to probe.
(And as a side effect disables auto-probing of all devices.)

When naming it, please take a fresh view.
Imagine you are defining this option and an auto-probe option.

The discussion assumes the user is familiar with auto-probe, and expects auto-probe. Don't design based on that.

-Morten