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 E8AFAA04B6; Mon, 12 Oct 2020 10:10:32 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 001F81D621; Mon, 12 Oct 2020 10:09:46 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by dpdk.org (Postfix) with ESMTP id 71B921D621 for ; Mon, 12 Oct 2020 10:09:44 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 28D6B7F4ED; Mon, 12 Oct 2020 11:09:43 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 28D6B7F4ED DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1602490183; bh=2MefD32wrD/6NZD398TzF9KXbdcXMLg5hnMxlQOq7nw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=eds+kp0o/6ciVikz/esI83fpx5ct8EHR4G0IxuwfGD7E0TIkql0FFGCnuWb/vDsR1 uv/dLmqmPZ060sFEQmeOobQE1aXqXql1INnq7M1LpNaPNMbOHXYsxMBGlgicLh7czU Fcb4+NojeevmISDalDRoOyc/MDgyv9vL3ULR+riE= To: Thomas Monjalon , Kalesh A P Cc: dev@dpdk.org, ferruh.yigit@intel.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> <2251820.FElH11MiGr@thomas> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: Date: Mon, 12 Oct 2020 11:09:42 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <2251820.FElH11MiGr@thomas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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" On 10/12/20 12:29 AM, Thomas Monjalon wrote: > 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. What should be done if the state is not recoverable? >> 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? > >