> On Feb 15, 2017, at 2:06 PM, Jan Blunck <jblu...@infradead.org> wrote: > > On Wed, Feb 15, 2017 at 7:09 PM, Wiles, Keith <keith.wi...@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.
I do not think moving vdev to the front is going to really solve my use case it, as it will create more problems then solve. The real case here is if the application developer inits devices out of order then he can hit the bonding driver bug. The current solution does not really fix the problem only bandaid the problem for the common ordered case. Do we need to solve this problem, maybe not, but it needs to be documented or we need to provide a cleaner way for the application to startup all devices in the correct order. A possible way is to have callback to the application in the correct order for him to initialize the devices, but not a great solution per say. > > 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???? >> Regards, Keith
