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 98435A046B for ; Wed, 26 Jun 2019 23:03:46 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 653FA1E20; Wed, 26 Jun 2019 23:03:43 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 73A192956; Wed, 26 Jun 2019 23:03:38 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F11F922162; Wed, 26 Jun 2019 17:03:37 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 26 Jun 2019 17:03:38 -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=mesmtp; bh=CQ4wCPHvrdSQC3QM+LdsUyDqww4WivFuA97J9bOLD8U=; b=Ez72QEZ8riFE FmizqTNgMYoVi46uuDl+6fzI6f+3SIdHA6Emm9hl+YJAnKUjEovXgwHLQB5pb3yY 3XlcXHRxXf/U08NyYpHmsJ8NlzzmB10OByxG0UYxvkJA2KADTy1wNjTG6XVmcv5v 5s1W13F0pwezK4x37l6O+Xkvv0pj62Q= 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=CQ4wCPHvrdSQC3QM+LdsUyDqww4WivFuA97J9bOLD 8U=; b=Pcr0dep5qJ/aUcRSKjMZyx46f2jd4uVlsItkITc7eWSJwZIgAw1mhaKNc kg8PV/Li4Px3Sf4FiDrGAJiEtrTpytb9md3bSlaXUoF5CSWruXObfdz83NHQRr+w iT3+xrBXwxpnQt+9jmKg7BulY+f1a8xJKVQT9vk7KniLlXXD8SeV3SsQ00LKCRCZ jNcnZ8FU3Qw+HjuCtRfG1Toc42+tPQYBJCsHqs1ov/nc/x2eGqw6up88ipRRvwWQ 4r/wocAQQZDiaofDmc6Q4YcQ3w1fVfDvjF482fw68MP+AbBvE6Qmlkw1E13QNvC6 bdU37uRTJLqTALdgp/48qrC6VHEhQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeigdduiedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedu 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 205008005B; Wed, 26 Jun 2019 17:03:35 -0400 (EDT) From: Thomas Monjalon To: David Marchand Cc: dev@dpdk.org, Ilya Maximets , Anatoly Burakov , Jan Blunck , Qi Zhang , Kevin Traynor , dpdk stable , Gaetan Rivet Date: Wed, 26 Jun 2019 23:03:34 +0200 Message-ID: <3764324.XPBHOOOE6Y@xps> In-Reply-To: References: <20190606100228.19959-1-i.maximets@samsung.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] eal: fix positive error codes from probe/remove 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" 07/06/2019 10:32, David Marchand: > Thomas, > > - Calling unplug on a device that is not attached is a bit weird to me, all > the more so that we have rte_dev_probed(). > But there might be users calling directly the bus unplug api and not the > official api... > Does this enter the ABI stability perimeter? > If not, I would be for changing unplug api so that we only deal with 0 or < > 0 on remove path. Where the positive value is documented? If it's only a non-documented usage, I tend to think it can be changed. > On the plug side, is there a reason why we do not check for > rte_dev_probed() and let the bus replies that the device is already probed? A device can be re-probed to allow discovering new ports. > Does it have something to do with representors ? > Only guessing. Yes representors are a case of ports which can appear on a new probe. > - On the plug side again, can't we have an indication from the buses that > they have a driver that can handle the device rather than this odd (and > historical) > 0 return code? > This should not change the current behavior, just make the code a bit > easier to understand. The positive code is also used for white/blacklist. And I think we may need to try probing in order to give a final answer, in general case.