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 B72C9A0569; Thu, 12 Mar 2020 08:34:21 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E6E1B1BFA5; Thu, 12 Mar 2020 08:34:20 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 9ADBEFEB for ; Thu, 12 Mar 2020 08:34:19 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DCC452217D; Thu, 12 Mar 2020 03:34:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 12 Mar 2020 03:34:18 -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=owz17VdfaL/2tsJmmRo+x53U+v0I7j50amkDw2aLjFM=; b=Ov66RacceLup SZMiRm6Xle9gXozXPxfZ2R+a1GbmLQ39Nss1soH/aA0nqzpj0hVjSRqQRsRFx5Qw Nta3GW2Ic/TmQhyPkl/or/cN49FKeQrB4wEAHW1p7TN93hB9npqarK3YMb8trSeQ RaSOCDlMoqv9GBpEkzPCcZPzGiqLI5o= 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=fm2; bh=owz17VdfaL/2tsJmmRo+x53U+v0I7j50amkDw2aLj FM=; b=IhJNjbHxBNsVRxgTODDJVL2udWC7prSqWPjgDdB58hDSEYS7wRrAa/nLh Zf5EXHjwdi53K1tUFIkvw/ItbptZuIYP4RdJGR4fzdrM/8DmhGXWYeIlQIgQzJq2 aho57hdjA9yRfazuDmNivd4hAKVuFxImQK13OLaZuYeKZYfRqINqO5OTXirG1Mkj CTppppL1ZEDt3JABGbhfPtFN6cBvT29dcHpSz/dhKjDKVj/oG8gqYsZkwjpNgLuG tUBihgfP2GbnlcOpCHyTV/FnH4Cp1Rp1m3XQIHraQ2Ogql+r1opbJfCkmXOhLwm8 yqi4FFNmwiR2WPanyERII7BOMyg7Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddvgedguddvudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc fkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 2CA56328005E; Thu, 12 Mar 2020 03:34:18 -0400 (EDT) From: Thomas Monjalon To: Kalesh Anakkur Purayil Cc: dev@dpdk.org, ferruh.yigit@intel.com, declan.doherty@intel.com, arybchenko@solarflare.com Date: Thu, 12 Mar 2020 08:34:15 +0100 Message-ID: <1632406.X513TT2pbd@xps> In-Reply-To: References: <20200122101654.20824-1-kalesh-anakkur.purayil@broadcom.com> <1946963.KlZ2vcFHjT@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC PATCH 0/3] librte_ethdev: error recovery support 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" 12/03/2020 04:25, Kalesh Anakkur Purayil: > Hi Thomas, > > On Wed, Mar 11, 2020 at 6:49 PM Thomas Monjalon wrote: > > > 22/01/2020 11:16, Kalesh A P: > > > From: Kalesh AP > > > > > > This patch adds support for recovery event in rte_eth_event framework. > > > FW error and FW reset conditions would be managed by PMD. Driver uses > > > > "Driver"? THE driver? :) > > > > > RTE_ETH_EVENT_INTR_RESET event to notify the applications about the > > > FW reset or error. > > > > Which drivers doe that? > > > [Kalesh]: Second patch in this series implements this behavior in bnxt PMD. > Error recovery is a new feature added in bnxt PMD in 19.11. This change is > needed to support error recovery functionality. > > > > > > In such cases, PMD would need recovery events to > > > notify application about PMD has recovered from FW reset or FW error. > > > > Sorry I don't understand. You said application is notified of any error. > > But the PMD can recover from this error? So what is the error at the end? > > If the error is recovered why notifying the application? > > > [Kalesh] : Let me give you some insight on this. > > The error recovery solution is a protocol implemented between firmware and > bnxt PMD to recover from the fatal errors without a system reboot. There is > an alarm thread which constantly monitors the health of the firmware and > initiates a recovery when needed. > > There are two scenarios here: > > 1. Hardware or firmware encountered an error which firmware detected. > Firmware is in operational status here. In this case, firmware can reset > the chip and notify the driver about the reset. > 2. Hardware or firmware encountered an error but firmware is dead/hung. > Firmware is not in operational status. In this case, the only possible way > to recover the adapter is through host driver(bnxt PMD). > > In both cases, bnxt PMD reinitializes with the FW again after the reset. > During that recovery process, data path will be halted and any control path > operation would fail. So, bnxt PMD has to notify the application about this > reset/error event to prevent any activities from application during this > time. I think you are changing the meaning of the reset event. It was described like this: RTE_ETH_EVENT_INTR_RESET, /**< reset interrupt event, sent to VF on PF reset */ Please update this description as well. Of course, we'll need approval from other PMD maintainers to accept the new recovery API.