On Wed, Jun 14, 2023, at 21:33, Stephen Hemminger wrote: > 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.
Hello Stephen, I am not pushing for this series anymore. I wrote it to help other people, I guess they used another way since. If someone needs it, I can take a moment to reanimate it. I'm still using the PCI bus hack to force manual probing, as well as port hotplug to control strict ordering. I guess at this point this is the stable way of working with DPDK, instead of a proper documented option. Best regards, -- Gaetan Rivet
