[dpdk-dev] [PATCH v7 13/15] eal: add hotplug add/remove functions

Jan Blunck jblunck at infradead.org
Fri Jun 30 17:44:58 CEST 2017


On Fri, Jun 30, 2017 at 11:20 AM, Bruce Richardson
<bruce.richardson at intel.com> wrote:
> On Fri, Jun 30, 2017 at 11:11:42AM +0200, Gaėtan Rivet wrote:
>> On Fri, Jun 30, 2017 at 11:06:03AM +0200, Thomas Monjalon wrote:
>> > 29/06/2017 20:22, Jan Blunck:
>> > >  /**
>> > > + * Hotplug add a given device to a specific bus.
>> > > + *
>> > > + * @param busname
>> > > + *   The bus name the device is added to.
>> > > + * @param devname
>> > > + *   The device name. Based on this device name, eal will identify a driver
>> > > + *   capable of handling it and pass it to the driver probing function.
>> > > + * @param devargs
>> > > + *   Device arguments to be passed to the driver.
>> > > + * @return
>> > > + *   0 on success, negative on error.
>> > > + */
>> > > +int rte_eal_hotplug_add(const char *busname, const char *devname,
>> > > +                 const char *devargs);
>> >
>> > After the hotplug, we may need to get the rte_device.
>> > Should we add a struct **rte_device as parameter,
>> > or should we add a helper function to get the rte_device
>> > from busname and devname?
>>
>> Also possible: return a struct *rte_device and set rte_errno on error.
>>
> +1 for this option.

Given that the caller of this is usually something that injects events
from the system I wonder what it is going to do with a rte_device
reference. Additionally to what the caller knows anyway (name,
numa_node, devargs) it can check if a driver got assigned. Sure the
caller could upcast conditionally based on the busname ...

At this point I guess the control plane would anyway want to get
access to a high-level object, e.g. the rte_ethdev. I believe it is
better to decouple this through callbacks that can get registered with
individual buses.


More information about the dev mailing list