From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f195.google.com (mail-wr0-f195.google.com [209.85.128.195]) by dpdk.org (Postfix) with ESMTP id A2E5A1C0B for ; Fri, 30 Jun 2017 17:44:59 +0200 (CEST) Received: by mail-wr0-f195.google.com with SMTP id x23so39541208wrb.0 for ; Fri, 30 Jun 2017 08:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=Eo4M9AL2CBgEnxO/8Q6RNaB0/xb1nRWVTC3PjJHMeMA=; b=M/BBiq1yHW8jGK6658oE91F9+SKLe9lizbWqwDQE/AHyhuU5UjG3nZJ5ZwIGS7lbDG waaPKSouMH+stvY1Uv1a+hOVoHhtuD2qdMSx77rYq/TRgRu3ZBEYt/PlQcmY9h9SmqcS /c7hh+Vt9S0YujI+mbuEyQvHIyQBBS8Pn2axOuWOo5ducwiux6yKkRv/aQVjh+UFuXFb hAoFdE4cPpD7cnuiRGmqHplE6So7JeGLYuzrBZ/fbQNjeKHNfTruA2gxlEvv7vPbHL1N QEQKDkPSWOzhRujwLPA+9xGynfDS+WOeLa2JdLLV9T2pEak2xQGfjirOHAbQAJ1/dZUf zTvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=Eo4M9AL2CBgEnxO/8Q6RNaB0/xb1nRWVTC3PjJHMeMA=; b=NXCajzRq2eE+TPqwvOh25h/mtmwVnxLDKzCR6LrCiTbmrKNMyg78oPsuvmFrrEtc/P e7CkIu01EC6qpsULPi8xXr6XBTfe6qqeuUnuHLV0DdhgYllVZONY8YMjT2ApbF4fRe58 wQoSMTFkbsPhc7HlGKCiqBBSZoYDQtPNgLlLGKxE8/xOVukOdgZ2xKcu7glHSCpt92GQ E5Wy5BO7TK2IfjcomvQ0/uw39sKOJEZETSsEftyEG2bTQmJek53j69e+ZsZQZqC4UHII HZz8FoF1/rpRKWtSU3DvnARx85HiChImxxcYjWbfLFnJmCW+MqDsqQ/N1JH2xQfrbwDB CQHw== X-Gm-Message-State: AKS2vOyKCMbRFueocsFrJ4vuSFsPtXDvAP9aTQfweoEE7CqtEEDpMpMb 8RhzySptLL+05iHRtmikEacZ3aUXlg== X-Received: by 10.223.142.80 with SMTP id n74mr30159043wrb.131.1498837499243; Fri, 30 Jun 2017 08:44:59 -0700 (PDT) MIME-Version: 1.0 Sender: jblunck@gmail.com Received: by 10.28.5.136 with HTTP; Fri, 30 Jun 2017 08:44:58 -0700 (PDT) In-Reply-To: <20170630092017.GA18672@bricha3-MOBL3.ger.corp.intel.com> References: <20170629182206.1072-1-jblunck@infradead.org> <20170629182206.1072-14-jblunck@infradead.org> <2830134.KdhWyS32Ir@xps> <20170630091141.GM13355@bidouze.vm.6wind.com> <20170630092017.GA18672@bricha3-MOBL3.ger.corp.intel.com> From: Jan Blunck Date: Fri, 30 Jun 2017 17:44:58 +0200 X-Google-Sender-Auth: _dYKN1eMa9_eoRlNeGNGMl6aIkM Message-ID: To: Bruce Richardson Cc: =?UTF-8?Q?Ga=C3=ABtan_Rivet?= , Thomas Monjalon , dev , Shreyansh Jain Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 15:44:59 -0000 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 identify = a driver >> > > + * capable of handling it and pass it to the driver probing funct= ion. >> > > + * @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.