On Sat, Mar 7, 2015 at 12:43 AM, Stephen Hemminger < stephen at networkplumber.org> wrote:
> On Fri, 6 Mar 2015 23:04:33 +0100 > David Marchand <david.marchand at 6wind.com> wrote: > > > In the end, the fix would be to move rte_eal_intr_init() after > rte_eal_dev_init(). > > > That would work, but was worried it would break other devices. > I had checked the pmds before proposing. rte_intr_* api is called only from the pdev (meaning pci) drivers at the moment. rte_eal_dev_init() means we are still in the "pmd init" phase for the pdev drivers which means we are still initialising per-driver things for them since they have no idea of the devices to handle (the devices are discovered later with the pci scan). In this phase, the code tells that they are not registering interrupts (and I don't see how they could register interrupts without knowing devices). The only problem would be for future vdev drivers (current drivers do not use rte_intr_*). But this problem would occur because the driver/device datamodel is not consistent. If we could rework this to have devices instantiated at the same phase, then the problem won't happen. So, we can hope we will have reworked the driver/device datamodel in dpdk, before this problem hits us. I only had checked the pmds, so I may have missed something else that uses interrupts (if any) but I think this is worth trying and fixing for 2.0. Thomas, opinion ? -- David Marchand
