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

Jan Blunck jblunck at infradead.org
Wed Jun 28 13:58:32 CEST 2017


On Wed, Jun 28, 2017 at 1:44 PM, Thomas Monjalon <thomas at monjalon.net> wrote:
> 27/06/2017 21:03, Jan Blunck:
>> On Tue, Jun 27, 2017 at 6:11 PM, Gaetan Rivet <gaetan.rivet at 6wind.com> wrote:
>> > --- a/lib/librte_eal/common/include/rte_bus.h
>> > +++ b/lib/librte_eal/common/include/rte_bus.h
>> >  /**
>> > + * Implementation specific probe function which is responsible for linking
>> > + * devices on that bus with applicable drivers.
>> > + * The plugged device might already have been used previously by the bus,
>> > + * in which case some buses might prefer to detect and re-use the relevant
>> > + * information pertaining to this device.
>> > + *
>> > + * @param da
>> > + *     Device declaration.
>> > + *
>> > + * @return
>> > + *     The pointer to a valid rte_device usable by the bus on success.
>> > + *     NULL on error. rte_errno is then set.
>> > + */
>> > +typedef struct rte_device * (*rte_bus_plug_t)(struct rte_devargs *da);
>>
>> Shouldn't this be orthogonal to unplug() and take a rte_device. You
>> should only be able to plug devices that have been found by scan
>> before.
>
> Plugging a device that has been scanned before is a special case.
> In a true hotplug scenario, we could use this plug function passing
> a devargs.
> I don't see any issue passing rte_devargs to plug and rte_device to unplug.

What do you mean by "true hotplug"?

The problem with this is that passing just rte_devargs to plug()
requires the bus to parse and enrich the rte_devargs with bus
specifics. From there it gets folded into the to-be-created bus
specific rte_XXX_device. This makes it unnecessarily complicated and
even worse it adds a second code path how devices come alive.

When we get notified about a hotplug event we already know which bus
this event belongs to:

1. scan the bus for incoming devices
2. plug single device with devargs and probe for drivers

Makes sense?


More information about the dev mailing list