On Wednesday 04 January 2017 03:16 AM, Thomas Monjalon wrote:
2016-12-26 18:53, Shreyansh Jain:--- a/lib/librte_eal/linuxapp/eal/eal.c +++ b/lib/librte_eal/linuxapp/eal/eal.c @@ -844,6 +845,9 @@ rte_eal_init(int argc, char **argv) if (rte_eal_intr_init() < 0) rte_panic("Cannot init interrupt-handling thread\n");+ if (rte_eal_bus_scan()) + rte_panic("Cannot scan the buses for devices\n");Yes, definitely. Just one scan functions which scan registered bus.@@ -884,6 +888,9 @@ rte_eal_init(int argc, char **argv) if (rte_eal_pci_probe()) rte_panic("Cannot probe PCI\n"); + if (rte_eal_bus_probe()) + rte_panic("Cannot probe devices\n"); + if (rte_eal_dev_init() < 0) rte_panic("Cannot init pmd devices\n");What is the benefit of initializing (probe) a device outside of the scan? Currently, it is done in two steps, so you are keeping the same behaviour.
Yes, only for compatibility to existing model of two-step process. Ideally, only a single step is enough (init->probe). During the discussion in [1] also this point was raised - at that time for VDEV and applicability to PCI. [1] http://dpdk.org/ml/archives/dev/2016-December/051306.html If you want, I can merge these two. I postponed it because 1) it is an independent change and should really impact bus and 2) I was not sure of dependency of init *before* pthread_create for all workers.
I imagine a model where the scan function decide to initialize the device and can require some help from a callback to make this decision. So the whitelist/blacklist policy can be implemented with callbacks at the scan level and possibly the responsibility of the application. Note that the callback model would be a change for a next release.
Agree. But, that is not really part of Bus patches - isn't it? Or, you want to change that with this series?
