From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 2E00916E for ; Fri, 30 Jun 2017 18:14:00 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id b184so50921457wme.1 for ; Fri, 30 Jun 2017 09:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=02hf9+oCS/FqOJZmVsCCtpi2VRbU5+Vc0so6SmTTq8g=; b=bpXfYo84YCJlYo5AThSUIPaiHnMLVE2gjxfr0FbYnEImcyZSZ0sbmasioP2ThzQPKW cQXlN+489fN9CT5yQqifUiWA2bPDbiJlP82bQHx4XebgiZVbYwjBdnoYck2E0fieWrjX fCXkbrGXNBtXwJXV66jomOD4LfhnbWdf4S/qyJcpnbWOTZIXz2W6PC3gfMSor5k7MOjm ndhJllZETxVIsWC1zCqsQx4z3+MwBcKM1N6E8rku32/UKEXW1aOxrtN6Hlj/LCE2oy2f LCynr2f8/x51YTTzc41OKPBwsi2Fj1N7xL+kuv/SAG2gz5aexvYyN8xBHwnw7RDvUW/U v+/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=02hf9+oCS/FqOJZmVsCCtpi2VRbU5+Vc0so6SmTTq8g=; b=kpwCpaDQ1R16cwucKAwalfoBRAEuWbXD0ctMkNfiW9DCembkc60bvoH1t8e1dukEMh 3/kXGWRUT3Emp5IwvlCSX3aoo6X3ozqGJ8EbVADjADW5jvYln5Pn7BSAbWmG15Omorxk oHDHrzKUkkMGPkslDO1Lisgg9YwlSEd+Z2ggXoW/T0W/NK/qqsse5yYm7pfqmhPCo4tE Kvrxk/+WYUdXADmdz+a07gks5d529sggRjUuiitGu88UFunMlzzkW5VBzigkdUj8Zpp9 TMtGG1MACS4UpLPxUr51p2JrdSfia8TzSjWD2Afdxv55soEulZA7y8JnzAyZpRF7cUvo 7x+A== X-Gm-Message-State: AKS2vOysaTpV8kwv2an1wVdC5pSfqB9Lt35p98dRmcBNUc/IuVHS748I uDt0uNEWBiMBQkhR X-Received: by 10.28.55.68 with SMTP id e65mr16473765wma.52.1498839239831; Fri, 30 Jun 2017 09:13:59 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id o4sm8445445wrb.27.2017.06.30.09.13.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jun 2017 09:13:59 -0700 (PDT) Date: Fri, 30 Jun 2017 18:13:51 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Thomas Monjalon Cc: Jan Blunck , Bruce Richardson , dev@dpdk.org, Shreyansh Jain Message-ID: <20170630161351.GO13355@bidouze.vm.6wind.com> References: <20170630092017.GA18672@bricha3-MOBL3.ger.corp.intel.com> <1838805.2PTbaQPJV0@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1838805.2PTbaQPJV0@xps> User-Agent: Mutt/1.5.23 (2014-03-12) 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:14:00 -0000 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. -- Gaëtan Rivet 6WIND