From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D9E8C48BD3 for ; Wed, 26 Jun 2019 21:03:47 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id E5BFB2086D for ; Wed, 26 Jun 2019 21:03:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=monjalon.net header.i=@monjalon.net header.b="Ez72QEZ8"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="Pcr0dep5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E5BFB2086D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=monjalon.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org 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.