From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id A00BA16E for ; Fri, 30 Jun 2017 18:03:18 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3936B20F94; Fri, 30 Jun 2017 12:03:18 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 30 Jun 2017 12:03:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=EppMhGVwiKDGdCe b1fK8xm0x6343tJXQ6T9+SyOUSa4=; b=Gq9spwcAfCAYXsYJIAAqVHx3+haTno2 rUs4SGw05LjiB5A5l9vcpQ97fmRNFLuviVZY8wHP0FOAKCEJ77ElbfBH7BW8I6dY lcHghYItZ/flfLFUtU7qLClTnadJ5ZwxBBtGXaWpbs1p9j34yN8Ttvskl2w8JMd7 IiqbbIh0FU/U= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=EppMhGVwiKDGdCeb1fK8xm0x6343tJXQ6T9+SyOUSa4=; b=WQGb5lij 7ZjF+g95G6FjByq8dth/FUJaH2dO+rKVZcyuVTDnod0lxJhtH0o9oG6OrzMfuR8c LImRXYf56QFUelKcGpKYo6EpPnJQx2P1/PbvCx5BoeShXl2kRRT8vdoCJ0zsudfE vUAEMcpADF/hztx7rAbmz5S0N4FprA8knzl1GsnX9RnsCnnFsOVVBBbZdyjlcrpq fwQdmeDQAJ81CSP33juF+fBRByaRfgxFd+q4ZLY/k5z9loTDunyANuDDQ0HFQWI4 u9pqeLM4YNjzw4KRt2WL2Srvey2F1gQsh5t3kYIWjg7uHp8zHmyMF/JU1lrSUyxa nbDpTRVWP4hu/Q== X-ME-Sender: X-Sasl-enc: Fup5olWft3JmN+wkJ8b/DHLcHvJwDfCtenC8QRPjMRSE 1498838597 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id D2C3624346; Fri, 30 Jun 2017 12:03:17 -0400 (EDT) From: Thomas Monjalon To: Jan Blunck Cc: Bruce Richardson , =?ISO-8859-1?Q?Ga=EBtan?= Rivet , dev@dpdk.org, Shreyansh Jain Date: Fri, 30 Jun 2017 18:03:17 +0200 Message-ID: <1838805.2PTbaQPJV0@xps> In-Reply-To: References: <20170630092017.GA18672@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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:03:19 -0000 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 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.