[dpdk-dev] [PATCH v6 05/11] bus: introduce hotplug functionality

[Gaëtan Rivet]

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.rivet at 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