From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 67DB5A0351; Thu, 6 Aug 2020 13:43:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B77AC2BF2; Thu, 6 Aug 2020 13:43:42 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 7F2A529D2 for ; Thu, 6 Aug 2020 13:43:41 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C87445C0181; Thu, 6 Aug 2020 07:43:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 06 Aug 2020 07:43:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= KdyEmamFaSSqp97DY0SpWFl6aWbM4SEUx6+REPRceEg=; b=VY1ypi+JFlBMjkLK 7m9YsBVeu6rUlIj10S/BgqDZQS/Sg2fXvtaMbM1z45qsjMQManJ0i+66T5FuzsWd YcrVOSAZj/r/xQzlG+swZ9DXb2nUODGAw50BKLMoLSOJ6CdbGwS1AuSU6bedtr8b tgsM0TH27APneY5M/1M93K7/3gt0EVeY2JDFX/652VtYBQnW8D8RJ98odyxRr7bR +DHDimygJSMYal3MQxJyzkFoUIHCUXvL+PogpYKFbPqrinJucwGANlzE2CwgyGen YEhDJqJnzkRnRw4zVAJ/Sfu41P8I5JDUFoiKmNSDInmJHx5DE8a8yHxxW1WOdmX4 s7dPQA== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=KdyEmamFaSSqp97DY0SpWFl6aWbM4SEUx6+REPRce Eg=; b=Nm6kuSYGYdH7tGWWaByrQmxiyFq23kyVX8EvHrBtGgyO5sYUnOquVzbJC QVrG5nhHOUSQEeoy2VTY1j1hAg8WWb8p1SN3HPVW/taYTFY2XkRcr0oitYmnKauy 1VAZtTSteU3XpPRbW6yjGnLNXJnkjatQbNnvMv09oxu1BvzqLRVfaUo3oBiERt3a pakMvX+p747akD4qu/Tn1JXPlkQVqMV2zxoX2N2srvqx1vI9IrdFEW6N1AXT8UNL N7zPyKFkfIOSv6MpeesifJ+VG1FI6kn9sE/9k14K4PQnfD/7d/kOfhamtD0HXkeN s/DVf8ZHNPsMRhNpy1dnjdwp8RIsQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrkedtgdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 0626430600A9; Thu, 6 Aug 2020 07:43:38 -0400 (EDT) From: Thomas Monjalon To: Maxime Coquelin Cc: dev@dpdk.org, grive@u256.net, david.marchand@redhat.com, wenzhuo.lu@intel.com, beilei.xing@intel.com, bernard.iremonger@intel.com, ferruh.yigit@intel.com, akhil.goyal@nxp.com Date: Thu, 06 Aug 2020 13:43:36 +0200 Message-ID: <18395771.BYCcGiSWyI@thomas> In-Reply-To: References: <20200625080430.1392037-1-maxime.coquelin@redhat.com> <2896958.gFCnIyvRxY@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 (v20.11) 2/2] eal: improve device probing API 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 06/08/2020 12:29, Maxime Coquelin: > On 8/6/20 1:33 AM, Thomas Monjalon wrote: > > 25/06/2020 10:04, Maxime Coquelin: > >> This patch makes rte_dev_probe() to return the > >> rte_device pointer on success and NULL on error > >> instead of returning 0 on success and negative > >> value on error. > >> > >> The goal is to avoid that the calling application > >> iterates the devices list afterwards to retrieve > >> the pointer. Retrieving the pointer is required > >> for calling rte_dev_remove() later. > >> > >> Signed-off-by: Maxime Coquelin > >> --- > >> --- a/lib/librte_eal/include/rte_dev.h > >> +++ b/lib/librte_eal/include/rte_dev.h > >> @@ -148,9 +148,9 @@ int rte_eal_hotplug_add(const char *busname, const char *devname, > >> * @param devargs > >> * Device arguments including bus, class and driver properties. > >> * @return > >> - * 0 on success, negative on error. > >> + * Generic device pointer on success, NULL on error. > >> */ > >> -int rte_dev_probe(const char *devargs); > >> +struct rte_device *rte_dev_probe(const char *devargs); > > > > Sorry for not catching it earlier, I think this change is against > > the idea of having a generic devargs syntax. > > One string could identify multiple devices. > > That sounds fragile to me. What if one of the multiple devices fails to > probe? Do the other ones are going to be removed? No, what is correctly probed should not be rolled back in my opinion. > > And a successful probe does not mean there is a new rte_device > > (can be an update, allowing more ports on the same device). > > This should be done by a separate API in my opinion, ports may be seen > as a sub-function of the device. > > But anyway, I am fine with dropping it. It is not blocking vDPA probing, > just making it more cumbersome. Apps should not iterate on devices. vDPA should have an event mechanism like in ethdev: a callback with RTE_ETH_EVENT_NEW is called for each new port probed.