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 A6236A04B6; Sun, 11 Oct 2020 23:29:44 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4EB671C2F7; Sun, 11 Oct 2020 23:29:42 +0200 (CEST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id C9E351BACE for ; Sun, 11 Oct 2020 23:29:40 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 53CD5EB0; Sun, 11 Oct 2020 17:29:38 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 11 Oct 2020 17:29: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=fm2; bh= Uqs72H1GlZWavd2MRtTJRsDW20weoifc8wlKLbmwots=; b=sayUZYWKIo3ghe8d xW++2naXTqWT8KbUZRRItPaIB8YExcuaUPWJDKSFOoGmfV86uriuI3gnDw6nT7QU NE9jy6WghGSWZj/8PaknwiBikU9ZYYgq9BbLKm7V0/AHSxdxm5Pdn+8qldnRIntd WZURJg2GcUUcYmKeSTSjEWpVA1CzPhBVTQ1LpRXMx/rF1Qdfe60PeNcKS/SnaA4L WsnEFpwKJFCay9LeFuCBrceFEAqmQx8i3AbTBWl6tk4a9CFbsLKMpcMpflIV0cNH 0lalPUu7mPnLbJa248shkv+zQnUQrlbm2+DFFuv6j6CHUlHcj1jIRqtaFDzZyec+ 7hRZzA== 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=fm1; bh=Uqs72H1GlZWavd2MRtTJRsDW20weoifc8wlKLbmwo ts=; b=MWmOuHTNLxN/IZ6M5rloVVCQnZ9O7M9uXIJcVua93DNNZEK/ikGTLp03g rKh/FdC7OWV5qCV5Kcwgsf7JVdSDYKImopYG5VFVvObucKU5LcQIx3nU16TCRi3u jN/0OqKbZs6CCYeNxoGh1g20rrLefYub8MplRYOkfnwUUoq3DPdHgcCb9EHHgwzi 1pj3gThZtvA7IH87ZwBXMIegsjX8Deqm8dQqpJKBBqFUWHUdfNnv1x/0NUg7/QEZ 145tnsaTo43ReTnuP+dx8Yq1Cw8tvPEP1azQZrFL4Kf8DAlgHFNg5eRsLbzMi7ji v11wozh8Y9he06XiuKD5gg3ze2wDA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrheehgdduieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkjghfggfgtgesthfure dttddtvdenucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcuoehthhhomhgrshes mhhonhhjrghlohhnrdhnvghtqeenucggtffrrghtthgvrhhnpedugefgvdefudfftdefge elgffhueekgfffhfeujedtteeutdejueeiiedvffegheenucfkphepjeejrddufeegrddv tdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 D3C143064674; Sun, 11 Oct 2020 17:29:36 -0400 (EDT) From: Thomas Monjalon To: Kalesh A P Cc: dev@dpdk.org, ferruh.yigit@intel.com, arybchenko@solarflare.com Date: Sun, 11 Oct 2020 23:29:35 +0200 Message-ID: <2251820.FElH11MiGr@thomas> In-Reply-To: <20201009034832.10302-2-kalesh-anakkur.purayil@broadcom.com> References: <20200122101654.20824-1-kalesh-anakkur.purayil@broadcom.com> <20201009034832.10302-1-kalesh-anakkur.purayil@broadcom.com> <20201009034832.10302-2-kalesh-anakkur.purayil@broadcom.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v6 1/3] ethdev: support device reset and recovery events 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" 09/10/2020 05:48, Kalesh A P: > From: Kalesh AP > > Adding support for device reset and recovery events in the > rte_eth_event framework. FW error and FW reset conditions would be > managed internally by PMD without needing application intervention. > In such cases, PMD would need reset/recovery events to notify application > that PMD is undergoing a reset. > > Signed-off-by: Somnath Kotur > Signed-off-by: Kalesh AP > Reviewed-by: Ajit Khaparde > Reviewed-by: Asaf Penso The ethdev maintainers are not Cc'ed. Please use the option --cc-cmd devtools/get-maintainer.sh > +Error recovery support > +~~~~~~~~~~~~~~~~~~~~~~ > + > +When the PMD detects a FW reset or error condition, it will try to recover > +from the error without needing the application intervention. In such cases, > +PMD would need events to notify the application that it is undergoing > +an error recovery. > + > +The PMD will trigger RTE_ETH_EVENT_ERR_RECOVERING event to notify the > +application that PMD detected a FW reset or FW error condition. PMD will > +try to recover from the error by itself. Data path will be halted and > +control path operations would fail during the recovery period. > + > +The PMD will trigger RTE_ETH_EVENT_RECOVERED event to notify the application > +that the it has recovered from the error condition. Control path and data path > +are up now. Since the device undergone a reset, flow rules offloaded prior to > +the reset will be lost and the application has to recreate the rules again. > diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h > index 9759f13..9b4b015 100644 > --- a/lib/librte_ethdev/rte_ethdev.h > +++ b/lib/librte_ethdev/rte_ethdev.h > @@ -3207,6 +3207,23 @@ enum rte_eth_event_type { > RTE_ETH_EVENT_DESTROY, /**< port is released */ > RTE_ETH_EVENT_IPSEC, /**< IPsec offload related event */ > RTE_ETH_EVENT_FLOW_AGED,/**< New aged-out flows is detected */ > + RTE_ETH_EVENT_ERR_RECOVERING, > + /**< port recovering from an error > + * > + * PMD detected a FW reset or error condition. > + * PMD will try to recover from the error. > + * Data path will be halted and Control path operations > + * would fail at this time. > + */ Does it mean the application has nothing to do when receiving this event? I think the app should stop polling at least. > + RTE_ETH_EVENT_RECOVERED, > + /**< port recovered from an error > + * > + * PMD has recovered from the error condition. > + * Control path and Data path are up now. > + * Since the device undergone a reset, flow rules > + * offloaded prior to the reset will be lost and > + * the application has to recreate the rules again. > + */ Please be more precise. Should the app re-configure the port, setup the queues, start the port?