From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v7 13/15] eal: add hotplug add/remove functions Date: Fri, 30 Jun 2017 18:29:01 +0200 Message-ID: <2133726.lcE2RmnHbq@xps> References: <20170630161351.GO13355@bidouze.vm.6wind.com> <20170630162544.GB17400@bricha3-MOBL3.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Ga=EBtan?= Rivet , dev@dpdk.org, Shreyansh Jain To: Bruce Richardson , Jan Blunck Return-path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 1A593235 for ; Fri, 30 Jun 2017 18:29:03 +0200 (CEST) In-Reply-To: <20170630162544.GB17400@bricha3-MOBL3.ger.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 30/06/2017 18:25, Bruce Richardson: > On Fri, Jun 30, 2017 at 06:13:51PM +0200, Ga=C3=ABtan Rivet wrote: > > On Fri, Jun 30, 2017 at 06:03:17PM +0200, Thomas Monjalon wrote: > > > 30/06/2017 17:44, Jan Blunck: > > > > On Fri, Jun 30, 2017 at 11:20 AM, Bruce Richardson > > > > wrote: > > > > > On Fri, Jun 30, 2017 at 11:11:42AM +0200, Ga=C4=97tan 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 i= dentify a driver > > > > >> > > + * capable of handling it and pass it to the driver probi= ng 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 *de= vname, > > > > >> > > + 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. > > > >=20 > > > > Given that the caller of this is usually something that injects eve= nts > > > > 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 ... > > > >=20 > > > > 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 w= ith > > > > individual buses. > > >=20 > > > I think Gaetan has an example of use of rte_device after plugging > > > with the failsafe PMD (managing slaves). > > > Anyway, it can be discussed later with a real example of use if neede= d. > > > We have a couple of weeks before freezing the API. > >=20 > > The rte_device should be accessible from the rte_eth_dev anyway so it > > does not make much difference. As long as a handle on the device is > > available. It is of course possible to add yet another callback to > > search the device just plugged, but I don't see a reason here not to do > > it in one pass. > >=20 > At this point in the process we just need to get in what we can. >=20 > Given there is so much discussion I would suggest we apply what we have > now, but mark the new APIs as "experimental" at this point. That should > allow us to test them, and build upon them without holding us back if we > do need to change them in the next release. Once everyone is happy with > the final result, we can lock them down then. It seems premature > to do so now, with the current discussion, but on the other hand > it seems foolish to not put what work has been done thus far > into a release as a starting point. I agree. Please Jan, add EXPERIMENTAL in the doxygen of the new hotplug API for your next version. Thanks