From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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: <xms:bFB0Xz9NZVmRsjboEAMG_9333a89bPQ6xD6RV51t-x33k3JBoVm2lA>
 <xme:bFB0X_uZkjPi-akvRgo79Okh1HXOevTOwosuQbGDW7lgunZsunnmjLDF3rgpS5dvB
 QILeuwFf447UbC5lA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfedvgdduvdcutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs
 ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf
 frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei
 iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih
 iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho
 nhdrnhgvth
X-ME-Proxy: <xmx:bFB0XxBqh0B_gi7Ilt58A8xHLRokLRwL_gIidD1OdZ5PJfSewB9aSA>
 <xmx:bFB0X_f0lQ77v2o2FQ7cawIjqu2uffDSlxHynXzXQ-5VvHcmxNzhjw>
 <xmx:bFB0X4P75jHeQvsRJBVObNz2QKPde8OM7YtDRoAdLyOMDsyucTTcYg>
 <xmx:bVB0XxbWtlhQu9YxAwXuHeOhaaDJhh7CTGXvm5cTIvMcwsHOlDr46w>
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 <thomas@monjalon.net>
To: Kalesh Anakkur Purayil <kalesh-anakkur.purayil@broadcom.com>
Cc: dev@dpdk.org, "Yigit, Ferruh" <ferruh.yigit@intel.com>,
 Ajit Kumar Khaparde <ajit.khaparde@broadcom.com>, arybchenko@solarflare.com
Date: Wed, 30 Sep 2020 11:31:22 +0200
Message-ID: <4519404.sAeCkK9CYH@thomas>
In-Reply-To: <CAH-L+nMSFxJFRhJv+7b6c_RZz+QMUjP02zt9JW-buAMA8VoE4g@mail.gmail.com>
References: <20200122101654.20824-1-kalesh-anakkur.purayil@broadcom.com>
 <3129125.UTyNnJLbx8@thomas>
 <CAH-L+nMSFxJFRhJv+7b6c_RZz+QMUjP02zt9JW-buAMA8VoE4g@mail.gmail.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

30/09/2020 10:35, Kalesh Anakkur Purayil:
> On Wed, Sep 30, 2020 at 1:21 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > > From: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
> > >
> > > 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.