From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH v7 13/15] eal: add hotplug add/remove
	functions
Date: Fri, 30 Jun 2017 18:03:17 +0200
Message-ID: <1838805.2PTbaQPJV0@xps>
References: <cover.1498577192.git.gaetan.rivet@6wind.com>
 <20170630092017.GA18672@bricha3-MOBL3.ger.corp.intel.com>
 <CALe+Z017UL7QQFyyHAzMK_u8Ca=chpeq6Nk9pHC+OtanXHgCCg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Bruce Richardson <bruce.richardson@intel.com>,
 =?ISO-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com>, dev@dpdk.org,
 Shreyansh Jain <shreyansh.jain@nxp.com>
To: Jan Blunck <jblunck@infradead.org>
Return-path: <dev-bounces@dpdk.org>
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
 [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id A00BA16E
 for <dev@dpdk.org>; Fri, 30 Jun 2017 18:03:18 +0200 (CEST)
In-Reply-To: <CALe+Z017UL7QQFyyHAzMK_u8Ca=chpeq6Nk9pHC+OtanXHgCCg@mail.gmail.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

30/06/2017 17:44, Jan Blunck:
> On Fri, Jun 30, 2017 at 11:20 AM, Bruce Richardson
> <bruce.richardson@intel.com> 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 identif=
y a driver
> >> > > + *   capable of handling it and pass it to the driver probing fun=
ction.
> >> > > + * @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.
>=20
> 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 ...
>=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 with
> individual buses.

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 needed.
We have a couple of weeks before freezing the API.