From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 3E0A11B03F for ; Fri, 19 Jan 2018 18:54:54 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B4C4F20AB3; Fri, 19 Jan 2018 12:54:53 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 19 Jan 2018 12:54:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=VLhjyOAQSuCQrLMYXbTL8aylCb 6W/LNBPKm9CupdHO8=; b=J9UEzZQ6BZrEjh0mQ+BhHZ+P5sUe1+MRFR5SIH3mRn fDXnYWuHWl1vPiNtA/2509dRO7HjKyNfxtEBmxZ+7+4xEV5xDBX25HcU9BAreUhz xwCDfovmVI+HwfGkMxeDlkS0A4nXfUivvhKDB50gFpky7yo6kjFZ7MsKHLRkcZdz 0= 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-sender:x-me-sender:x-sasl-enc; s=fm1; bh=VLhjyO AQSuCQrLMYXbTL8aylCb6W/LNBPKm9CupdHO8=; b=F8jyRT8HBDZFKt/W2jORtv E7JxX3WGxrP6japLeu+5q1H446Ck6TxrHDPT3rJvHbOsKpDIRH8t1StVuWqtiCyy UAgqF+V72v8xowtxwqVQ1IavWWbVS8ca+Jf6RqmsqI71R3AU/gwJgqPekMjMYTCX d1MdRvNucW+MYWOdUiFeEO/YIPmb9m8h3soaha4W47/wStqwD0/NiW8129MlC2n0 cU+Y4klktEKBJ/vgvEM0ATGMvxRj2rHnq9N3SUear2wosys9OYcxCNoDw1Ix7G5L Ry17FgQI5kKe0x0dtBFtXfWuaufgx/ZcBNaw20EA0WboR2VHyu/IOuyRaC8Pnxag == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 57A197E3D5; Fri, 19 Jan 2018 12:54:53 -0500 (EST) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, Matan Azrad , Adrien Mazarguil , Gaetan Rivet , Andrew Rybchenko , "Ananyev, Konstantin" , Alejandro Lucero , Jerin Jacob , Hemant Agrawal , Shahaf Shuler , Olivier MATZ , "Zhang, Helin" Date: Fri, 19 Jan 2018 18:54:18 +0100 Message-ID: <3568963.dcr6cRumit@xps> In-Reply-To: References: <1516220357-13013-1-git-send-email-matan@mellanox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v6 4/6] ethdev: adjust APIs removal error report 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, 19 Jan 2018 17:54:54 -0000 19/01/2018 17:19, Ferruh Yigit: > On 1/18/2018 6:10 PM, Matan Azrad wrote: > > From: Ferruh Yigit, Thursday, January 18, 2018 7:31 PM > >> This patch updates *all* ethdev public APIs to add if device is removed > >> check? > > > > Yes. > > > >> And each check goes to ethdev is_removed() dev_ops to ask if dev is > >> removed. > > Probably, if the REMOVED state setted in will not call device is_remove. > > > >> These must be better way of doing this, am I missing something. > > > > Suggest. > > With a silly analogy, this is like a blind person asking each time if he is dead > before talking to other person. > > At first glance I can think of a kind of watchdog timer can be implemented in > ethdev layer. It provides periodic checks and if device is dead it calls the > registered user callback function. > > This method presented as synchronous method but not triggered from side where > event happens, I mean not triggered from PMD but from application. > So does application doing polling continuously if device is dead? > Or if application is relying this patch to add a check in each API, what happens > if device removed during data processing, will app rely on asynchronous method? We cannot put a mutex on hardware removal :) So we have to live with errors due to removal. If we are trying to configure a removed device, the error will be not related to the root cause. This patch is just trying to improve the situation by returning an appropriate error code if removal can be detected. Note: the check is run only if there is an error and if the removal is not already detected. If I understand well, you prefer relying only on asynchronous hotplug events? Even if they come really late?