On Thu, Jun 29, 2017 at 09:20:30PM +0200, Jan Blunck wrote: > On Thu, Jun 29, 2017 at 2:59 PM, Gaëtan Rivet <gaetan.ri...@6wind.com> wrote: > > What can be done to go forward: > > > > - Define the API for rte_bus interrupt sources, configuration and > > triggers to allow the development of the needed subsystems. > > > > - Each device event sources should offer an event parser to transform > > them in device descriptions. Depending on the specifics of the source, > > different levels of info are available. > > > > - Redefine the requirements for bus->scan() to allow hotplugging. > > > > - Reduce the scope of plug() from (scan-one + probe) to (probe), as > > everything is now in place. > > > > Also see the series that I send out today. From my point of view we > are here already. >
Yes, your series is only a superficial departure from the v6. In the end, I see that your critics were pretty much only on interfaces and that you simply wanted it to be your way. You did not expose your reason for disagreeing, thus I threw a few ideas to at least make you either explicit your view or accept the current proposal. > > - Further hotplugging developments are then possible: add INTR_ADD > > support, with flexible device definition for example... A thing that > > is not yet possible with the current architecture but seemed to > > interest a few people. > > > > If we can agree that this is a way forward, do you think Jan that having > > the current plug() API hinders this plan? We can reduce its scope later, > > without changing current implementations as, as you said, a proper > > scan should be idempotent. The future API as envisionned is already > > respected, but right now the hotplug support in buses is a little more > > involved. Applications that will start using plug() right now would not > > have to be rewritten, as the requirements for plugging would still be > > fullfilled. > > > > We can support already hotplugging in DPDK. We can refine this support > > later to make it more generic and easier to implement for PMD > > maintainers. But I do not see this as a reason to block this support > > from being integrated right now. > > Indeed. I had hotplug support in the version of DPDK that I'm working > with for the last years. Don't get me wrong: I'm not arguing against > the inclusion of hotplug code. I just don't understand the reasoning > behind the implementation you proposed (with my original SOB) > especially since some of the things that you listed as going forward > are already there, are easy to fix or don't necessarily need to be > part of the DPDK EAL. > Don't get me wrong, I am not personally a proponent of these changes, but I wanted the current implementation to at least leave things open as I think a few people will push for this in a near future. But as far as I'm concerned, the hotplug support in DPDK will be sufficient in v17.08. > So lets try to get this right from the beginning. What is missing: > 1. document and verify that existing scan() implementations are idempotent > 2. example app with udev based hotplug > 3. check that the symbols are in the correct libraries (bus, pci, vdev) > > What am I missing? > Nothing on the technical side. -- Gaëtan Rivet 6WIND
