On Tue, Oct 1, 2019 at 7:39 PM Gaëtan Rivet <gaetan.ri...@6wind.com> wrote: > > On Tue, Oct 01, 2019 at 03:19:42PM +0530, Jerin Jacob wrote: > > On Tue, Oct 1, 2019 at 2:40 PM Gaėtan Rivet <gaetan.ri...@6wind.com> wrote: > > > > > > On Mon, Sep 30, 2019 at 11:53:33AM -0700, Stephen Hemminger wrote: > > > > On Mon, 30 Sep 2019 14:51:03 +0200 > > > > Gaetan Rivet <gaetan.ri...@6wind.com> 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 <gaetan.ri...@6wind.com> > > > > > > > > I have no problems with the patch, but it would help if there was better > > > > way to handle device naming policy in DPDK. Applications that depend on > > > > particular port number are prone to get broken by changes in surrounding > > > > OS or hardware environment. Just like Linux applications that are built > > > > to depend on "eth0"; which is unfortunately all too common. > > > > > > Hello Stephen, > > > > > > This patch is a way to avoid having the PCI bus defining the probe order > > > with the current hardware environment. It seems to be a step in the > > > right direction for the issue you identify. > > > > > > There is a tight coupling between device names and driver matches for > > > the vdev bus, but that seems difficult to avoid. > > > > > > Do you see other EAL APIs fostering an over reliance of downstream > > > systems on device names? > > > > > > I pushed a few months back a way to iterate / match devices by their > > > properties. If you identify other pain points, this could certainly be > > > improved as well. > > > > > > And this mode will be kicked in only when "--manual-probe" selected on > > eal arguments. > > So it won't change the behavior of the existing applications. > > If I read you correctly, if hardware independence is the proper way to > function, > we should switch entirely to it. > > I agree, but that means rewriting entirely the probe step of rte_bus. > This patch is a incremental step, I preferred to keep risks low.
+1 > > It is not clear from your remark whether you are considering this > limitation a good or a bad thing however :) I am considering it as a good step. > Can you be a bit more explicit? > > -- > Gaėtan Rivet > 6WIND
