Re: [dpdk-dev] [PATCH v1] eal: add manual probing option

On Tue, Oct 1, 2019 at 7:39 PM Gaëtan Rivet [off-list ref] wrote:

On Tue, Oct 01, 2019 at 03:19:42PM +0530, Jerin Jacob wrote:

quoted

On Tue, Oct 1, 2019 at 2:40 PM Gaėtan Rivet [off-list ref] wrote:

quoted

On Mon, Sep 30, 2019 at 11:53:33AM -0700, Stephen Hemminger wrote:

quoted

On Mon, 30 Sep 2019 14:51:03 +0200
Gaetan Rivet [off-list ref] wrote:

quoted

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 <redacted>

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