From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 881C52C2A for ; Wed, 28 Jun 2017 14:11:04 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1E30E20618; Wed, 28 Jun 2017 08:11:04 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 28 Jun 2017 08:11:04 -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=oHEGmvT7VwLZsfK f4JXCB72loM+7Vr0KZ31dM26sFoI=; b=p1yjmagu8DPWmV1G5Lvw0O/jwWhl9oj Lgv30cm7BmxucM47zdP+vEkP6sH/pgYoCXEFViFzoeM2fs/lPS1okVXsMV61XNwC /I+t+8NPfT6ruEUuRTv7VeYSnKtUwDbMD1Sah/8MyAWqVs2PL/mFOSV6svELrAFt 0oJIW2p9CfSI= 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=oHEGmvT7VwLZsfKf4JXCB72loM+7Vr0KZ31dM26sFoI=; b=gVRig3Kf lpPsMucf1VMKh2J3ldlan6IHnLGiuCVTxCk3Ippofw7lM4jheH8b1YMdyEHv9DDK wx4iZoaJqTzQiWerhI3khFl3RnW+GOxabrndC/dFTyRb+NJloyO6X8yj5ZYPzT4p bqoa2Py3G2a9bLmeP3Wgp8hc6oo2Lwh31B/ICFARKZr9csqhcyOy63asyvAOOCRe LbKAz2CbzQism7j+4RB+jsuh40dPBR0NYVwtd3WmreqVeFc5C67EIuBi1YHVEyEL XgvgFQ8psH7prnSlnbPJLt1sXDay+iBfbjqtJRVy7aTE41NeFmGZ8NtqewvuLdJD ouKkAu05/h1EdQ== X-ME-Sender: X-Sasl-enc: NURiXTYeo7tXh25RhuXXRfhb1RpiUmOcWKVc9aLua742 1498651863 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id CE1E77E32F; Wed, 28 Jun 2017 08:11:03 -0400 (EDT) From: Thomas Monjalon To: Jan Blunck Cc: dev@dpdk.org, Gaetan Rivet Date: Wed, 28 Jun 2017 14:11:03 +0200 Message-ID: <14287370.n4WKZa6dWl@xps> In-Reply-To: References: <4639959.eMbdazoqpE@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v6 05/11] bus: introduce hotplug functionality 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: Wed, 28 Jun 2017 12:11:04 -0000 28/06/2017 13:58, Jan Blunck: > On Wed, Jun 28, 2017 at 1:44 PM, Thomas Monjalon wrote: > > 27/06/2017 21:03, Jan Blunck: > >> On Tue, Jun 27, 2017 at 6:11 PM, Gaetan Rivet wrote: > >> > --- a/lib/librte_eal/common/include/rte_bus.h > >> > +++ b/lib/librte_eal/common/include/rte_bus.h > >> > /** > >> > + * Implementation specific probe function which is responsible for linking > >> > + * devices on that bus with applicable drivers. > >> > + * The plugged device might already have been used previously by the bus, > >> > + * in which case some buses might prefer to detect and re-use the relevant > >> > + * information pertaining to this device. > >> > + * > >> > + * @param da > >> > + * Device declaration. > >> > + * > >> > + * @return > >> > + * The pointer to a valid rte_device usable by the bus on success. > >> > + * NULL on error. rte_errno is then set. > >> > + */ > >> > +typedef struct rte_device * (*rte_bus_plug_t)(struct rte_devargs *da); > >> > >> Shouldn't this be orthogonal to unplug() and take a rte_device. You > >> should only be able to plug devices that have been found by scan > >> before. > > > > Plugging a device that has been scanned before is a special case. > > In a true hotplug scenario, we could use this plug function passing > > a devargs. > > I don't see any issue passing rte_devargs to plug and rte_device to unplug. > > What do you mean by "true hotplug"? I mean a kernel notification of a new device. > The problem with this is that passing just rte_devargs to plug() > requires the bus to parse and enrich the rte_devargs with bus > specifics. From there it gets folded into the to-be-created bus > specific rte_XXX_device. This makes it unnecessarily complicated and > even worse it adds a second code path how devices come alive. Just after the notification, the rte_device does not exist yet. So the plug function could share the same code as the scan function to get the metadata and create the device instance. > When we get notified about a hotplug event we already know which bus > this event belongs to: > > 1. scan the bus for incoming devices No need to scan every devices here. > 2. plug single device with devargs and probe for drivers > > Makes sense? I want to make sure there is no misunderstanding first :)