[dpdk-dev] [PATCH 3/7] eal: move virtual device probing into a bus

[Jan Blunck]

On Wed, Feb 15, 2017 at 7:09 PM, Wiles, Keith <keith.wiles at intel.com> wrote:
>
> I guess I see this differently, meaning we modified the system to put vdev devices last only because we do not have clean way to startup the system for pdev/vdev devices. The application should be agnostic to the devices being started and the system needs to determine the correct order without a chicken and egg problem. The test-pmd application just starts from 0 to n to initialize devices, which he should be able to do in any order. It is possible the application could initialize the devices (pdev/vdev) in any order, which the current design would break if they tried to init the bonding driver first.
>

Apart from the usability (vdevs always first) I wonder what kind of
usecase you are after. If I understand you correctly you want to:
- probe the virtual devices first
- start/configure the virtual devices last

... and only in some cases. From what I understand this requires a
domain specific way to model dependencies between ports, e.g. some
standardized device arguments parsed by EAL, and combined with your
requirement to assign the lowest port numbers for the vdev devices
even a scheduler.

Maybe we could reduce complexity by doing some simple things instead:
if you present the ports in reverse order to the users the vdev come
first. Probably this even increases usability because the most recent
created port is the one that the user is anyway most interested in.

> What happens if a vdev needs to be initialized before a pdev device?
>

This should never happen. The pdev devices offer a plain view on the
"system", which means no topology at all. The vdev devices are devices
that do not have a "system" representation, e.g. a library. I don't
think the EAL should offer an alternative API to system programming in
a way that you enumerate your PCI devices through a vdev that is
accessing hardware through another library.

> Not saying we need to solve this problem now, but need to figure this out some how. Maybe we need a priority for pdev/vdev devices to determine init order????
>