From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 95E092C2A for ; Fri, 30 Jun 2017 18:25:48 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jun 2017 09:25:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,287,1496127600"; d="scan'208";a="280710340" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.28]) by fmsmga004.fm.intel.com with SMTP; 30 Jun 2017 09:25:45 -0700 Received: by (sSMTP sendmail emulation); Fri, 30 Jun 2017 17:25:44 +0100 Date: Fri, 30 Jun 2017 17:25:44 +0100 From: Bruce Richardson To: =?iso-8859-1?Q?Ga=EBtan?= Rivet Cc: Thomas Monjalon , Jan Blunck , dev@dpdk.org, Shreyansh Jain Message-ID: <20170630162544.GB17400@bricha3-MOBL3.ger.corp.intel.com> References: <20170630092017.GA18672@bricha3-MOBL3.ger.corp.intel.com> <1838805.2PTbaQPJV0@xps> <20170630161351.GO13355@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170630161351.GO13355@bidouze.vm.6wind.com> Organization: Intel Research and =?iso-8859-1?Q?De=ACvel?= =?iso-8859-1?Q?opment?= Ireland Ltd. User-Agent: Mutt/1.8.1 (2017-04-11) Subject: Re: [dpdk-dev] [PATCH v7 13/15] eal: add hotplug add/remove functions X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 16:25:49 -0000 On Fri, Jun 30, 2017 at 06:13:51PM +0200, Gaëtan 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ė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. > > > > 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. > > 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. > At this point in the process we just need to get in what we can. 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. my 2c. /Bruce