04/10/2018 11:44, Doherty, Declan:

On 28/09/2018 5:40 PM, Thomas Monjalon wrote:

quoted

In the devargs syntax for device representors, it is possible to add
several devices at once: -w dbdf,representor=[0-3]
It will become a more frequent case when introducing wildcards
and ranges in the new devargs syntax.

If a devargs string is provided for probing, and updated with a bigger
range for a new probing, then we do not want it to fail because
part of this range was already probed previously.
There can be new ports to create from an existing rte_device.

That's why the checks for an already probed device
are moved as PMD responsibility.
Only the PMD knows the ports attached to one rte_device.

In the case of vdev, a global check is kept in insert_vdev(),
assuming that a vdev will always have only one port.
In the case of NXP buses, the probing is done only once (no hotplug),
though a check is added at bus level for consistency.

As another consequence of being able to probe in several steps,
the field rte_device.devargs must not be considered as a full
representation of the rte_device, but only the latest probing args.
Anyway, the field rte_device.devargs is used only for probing.

Signed-off-by: Thomas Monjalon <redacted>
---

Hey Thomas, did you consider of adding a driver flags to the rte_driver 
structure which has a driver re-probe flag. If this flag is disabled by 
default, current drivers could be left unmodified and any new driver 
which want to support re-probing enable this flag and then support the 
functionality in there probe function. Then we could check this flag in 
the bus driver on making a call on whether to re-probe.

I really don't know what is best:
- have a standard expectation for all drivers
- add a driver flag in order to remove a check

If your option is preferred, where the flag should be added?
- in rte_driver which has no flag at all so far
- in rte_pci_driver.drv_flags which may be enough (at least for now)

Opinions?