> -----Original Message----- <...snip...> > > this doesn't seem like an idea solution either. I'm not 100% clear why > > rte_eal_pci_probe is currently called by the application code and not > > initiated > > from within rte_eal_dev_init, if this was the case we would be able to > > figure > out > > a dependency tree for initialization of devices, based on the parsed input > > arguments without having extra user input to or multiple calls of > rte_eal_dev_init. > > > I agree, I think you should move it into its proper place within rte_eal_init, > though I think multiple calls to rte_eal_dev_init is perfectly acceptible in > this scenario. You certainly could parse the command line to build a > dependency > tree if you wish, though I don't think thats crruently overly complex. The > current > dependency tree is static at (physical devices, virtual devices, probe, > stacked > devices). If you need something more complex later, you can re-write it > freely > as it will be an internal library mechanism with no external visibility. >
How useful is this going to be? The more complicated the ethdev stacking being done, the better suited it is to being done via the C APIs, via code which can do analysis of the hardware and cores at runtime and make logical decisions? After all, even if we do have applications being run to use bonded devices at runtime in place of physical ones, the bonded devices don't actually replace the physical ones, so some other application logic is needed to ensure that the application knows to only use the bonded devices. In most cases simply having a port-mask suffices, but not all apps will have a port-mask parameter, and for those that do, it introduces complexity for the user counting out interfaces and trying to work out what ports will have what numbers to set the appropriate bits in the portmask.
