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 A7FBBA04B5; Wed, 30 Sep 2020 11:31:30 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 05C9B1D556; Wed, 30 Sep 2020 11:31:29 +0200 (CEST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by dpdk.org (Postfix) with ESMTP id 1CDF01D15A for ; Wed, 30 Sep 2020 11:31:28 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 94CE985B; Wed, 30 Sep 2020 05:31:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 30 Sep 2020 05:31:26 -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= yA+QdaBlhS3aoT8s558j7M1wvjKE/ka9QYnoDn8mLgA=; b=SBpkRUdEHzvIGQ9P RZED8BqxtX5aiZUE8OfqSBrEtTdEK1ouAHc6i+/yb8xOy99dMJcn/cggbb6XkTX6 CZvUu+tETBLpKG58XXp+TJauhirqf1U0bOVgJy3DXAf2hB0OoHv8iIxWirWex3L2 pNzIISinCnBZqr6dR5n4N/PH9TPRRMo6nSKCTCfT5mMMsvKuzK49eUaOE8qMQ9xf qdoaabAeEw5/19ZN192hvwKtHZyVUdsta7NXV740OFbrFlx/d+wMcY+SaVmcuM2y epRnKK0ljCec6cCWWB/r9FPsAgp6NCev/lQieJ/6kgBy/2MOhT9JFkM+z/kW4CzC ywrqzw== 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=yA+QdaBlhS3aoT8s558j7M1wvjKE/ka9QYnoDn8mL gA=; b=pCHo30T6+woF/zkxzKZ3U7JZRrgPAEhZMDZQ/ChfREDEBtMD9uP31VyBb uRF7b/GcGcyMAV4YelODlREfoV35bN/pNvRpFfW/iNGcqibJ6RV1qK9KggIpTis/ aDmdTOMoZKoW4BXl+qqQDPiPBPjuzq9fHbx/A91fuLjPdIIBbnWW8MtcEu8E8RFv fRzjZKMwXoMUanX3sZ3G7xII3RPEA/7c3I8DETzwymTp5DUP0/1uZHrESHhZ6KNa IGSELVaMepPswr49pZNOcMiGepv2jsxVGu/Ou18AUkmWKlPtrIcZZowVpjC5T7gi XRlJrwUDm4O8Rr15mGgU8/qiaOwvg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfedvgdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth 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 D50BB3280063; Wed, 30 Sep 2020 05:31:23 -0400 (EDT) From: Thomas Monjalon To: Kalesh Anakkur Purayil Cc: dev@dpdk.org, "Yigit, Ferruh" , Ajit Kumar Khaparde , arybchenko@solarflare.com Date: Wed, 30 Sep 2020 11:31:22 +0200 Message-ID: <4519404.sAeCkK9CYH@thomas> In-Reply-To: References: <20200122101654.20824-1-kalesh-anakkur.purayil@broadcom.com> <3129125.UTyNnJLbx8@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC PATCH v3 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" 30/09/2020 10:35, Kalesh Anakkur Purayil: > On Wed, Sep 30, 2020 at 1:21 PM Thomas Monjalon wrote: > > > 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. > > > > We already have this event: > > > > RTE_ETH_EVENT_INTR_RESET, > > /**< reset interrupt event, sent to VF on PF reset */ > > > > I don't know why "INTR" is in the name of this event, > > and I think it does not need to be restricted to VF. > > The application does not need to know whether the reset > > is caused by the PF, the FW or the HW. > > That's why I think you could share the same event. > > > > [Kalesh]: Yes. As you mentioned, this event is used for some other purpose. > I did not want to break the existing usage/purpose of this event. > For example, upon receiving the RTE_ETH_EVENT_INTR_RESET event OVS > application invokes rte_eth_dev_reset() to reset the port. > The aim here is to recover from the device error condition without the > intervention of Applications. PMD itself will recover from the error using > the protocol with FW. > > > > > > + RTE_ETH_EVENT_RESET, /**< port resetting from an error */ > > > + RTE_ETH_EVENT_RECOVERED, /**< port recovered from an error */ > > > > You ignored my previous comments: > > " > > What the application is supposed to do when receiving such event? > > How the application knows that flow rules were resetted? > > Is there any other configuration resetted? > > These informations must be explicit in the doxygen comments. > > " > > > [Kalesh]: Sorry, I missed it. > I am not sure what you meant by "These information must be explicit in the > doxygen comments ". > Could you please elaborate a little how to/where to put these details? /** is the start of a doxygen comment. This is the place (in the .h file) to explain to application developer what to do with the event. The code + the comments is what we call "the API". You should complete the description of RTE_ETH_EVENT_INTR_RESET as well: the need for calling rte_eth_dev_reset() was not explicit.