On Thu, 23 Jan 2020 10:58:13 +0100 Gaetan Rivet <gr...@u256.net> wrote:
> Add a new EAL option enabling manual probing in the EAL. > This command line option will configure the EAL so that buses > will not trigger their probe step on their own. > > Applications are then expected to hotplug devices as they see fit. > > Devices declared on the command line by the user (using -w and --vdev), > will be probed using the hotplug API, in the order they are declared. > > This has the effect of offering a way for users to control probe order > of their devices, for drivers requiring it. > > Signed-off-by: Gaetan Rivet <gr...@u256.net> > Acked-by : Vamsi Attunuru <vattun...@marvell.com> > Tested-by: Vamsi Attunuru <vattun...@marvell.com> > Reviewed-by: Jerin Jacob <jer...@marvell.com> > --- > > haven't heard many opinions on the matter, please shout if you see an issue > with this approach. > > @Slava: I have tested rather quickly that it does not break anything, > and that it works as intended for basic cases. > Can you test it further for your use-case and tell me if it works > fine? > > Beyond the obvious difference between both probe mode, something to keep in > mind: > while using -w on invalid devices would not block (PCI) bus probing, it will > stop manual > probing in its track. All devices need to exist and be valid device IDs. > > v2: fixed a few typos, map file (and used Travis to validate). > > Slava, are you able to test this patch? > > v3: properly fixed the map file (inherited 19.08 instead of 19.05). > > Added a function to set the probe manual from the application, > without having the user do it from the command line. > > Stopped spamming Slava about it, Vamsi was actually the one interested in > it! > > Standing issue worth chiming in: > > Currently manual-probe will cut off probing from all buses. > It could be interesting to be able to only cut buses supporting hotplug, > given that they are the one able to probe devices afterward. > > No real use-case for this right now, so leaving as-is. Might be worth > considering in the future. > > v4: Rebased on master, > Moved implementation in common EAL, > Used public API within the EAL to set the option, > Made the API experimental > > v5: added note in the Getting Started Guide. > > v6: Rebased on master > > see http://mails.dpdk.org/archives/dev/2020-January/154178.html > for reference to this version, linking v7 to v5 thread. > > v7: Updated author and SoB. > > doc/guides/linux_gsg/eal_args.include.rst | 13 ++++++ > doc/guides/rel_notes/release_20_02.rst | 9 ++++ > lib/librte_eal/common/eal_common_bus.c | 6 +++ > lib/librte_eal/common/eal_common_dev.c | 54 ++++++++++++++++++++++ > lib/librte_eal/common/eal_common_options.c | 8 ++++ > lib/librte_eal/common/eal_internal_cfg.h | 1 + > lib/librte_eal/common/eal_options.h | 2 + > lib/librte_eal/common/eal_private.h | 9 ++++ > lib/librte_eal/common/include/rte_eal.h | 36 +++++++++++++++ > lib/librte_eal/rte_eal_version.map | 4 ++ > 10 files changed, 142 insertions(+) This patch seems to have been held in limbo for 3 years. For me, it is ok, but concerned that it opens up a whole scenario of possible usages that may not be tested, and probably don't work. Testing all the possible combinations of probe ordering is a geometric problem. So if user submits bug then the response would have to be: Manual probing is an experimental option which may not work.
