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 61EE0A04BA; Wed, 7 Oct 2020 20:42:29 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7217D1B650; Wed, 7 Oct 2020 20:42:27 +0200 (CEST) Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com [209.85.210.68]) by dpdk.org (Postfix) with ESMTP id 8202FF3E for ; Wed, 7 Oct 2020 20:42:25 +0200 (CEST) Received: by mail-ot1-f68.google.com with SMTP id f10so3185133otb.6 for ; Wed, 07 Oct 2020 11:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WKHLG9m0Jvj4f1NUP+VUh8lVp1qIsnKlfXQJQQqZyvU=; b=e9Hqzin4PhgTceTU/bNdBuLYuVD03aWk+JuiOc/TDJn2HZL2g0/3bN8+dDrmLjNq58 L1h1w8kwoy+wjxQSXLH539JHW7MOQBMt4yjXdsfGSAzoIadIdo9LrCWi3bHrBLg0koWO Bjgza108Kf9a6aXYAX6aFoHrsHBKjuTxMuacM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WKHLG9m0Jvj4f1NUP+VUh8lVp1qIsnKlfXQJQQqZyvU=; b=RKOzy3w7Zc8lMiSHMibG1apIOxqUhji68t28EE//qEvGQkjjYe1EVZ0JG4lrD+AtrY H3eCWsAIXHDrCd6wM8aNbahb9D/OBYJOS8l1/XN+tebPrvmNvOTW95jhd04Fxhb0RCqd eYkfT8jLeuonaK1WMa/GdYcT/F6snyMYT/z/ZyeF+ie2UHNCqYTsYEUcIUTBCiq4S32W uEhxbHBcWRj2gMoI4PuHuTtJFpEUsVbCstqWY93DFhfOUdFS5GH8FiW2eKvq4ICTxsXG vlQjk4RwqGyD8B67P1Un970xXWZ/cau29qNah3iZa9EzkOi7W0EYAuBUmR/6ZEmsGFbW Qlbg== X-Gm-Message-State: AOAM530AYnFxzx+b2jgMye374hVtoq4iu9Lkc/GPkuZbWjMi0Sd+5md1 JE4bdAUq844jnqmqXZ/NeJpEV19rKwMB+CvoULfPuw== X-Google-Smtp-Source: ABdhPJxOUrhLJQ8KLnKbtMQCt48T4PIGG/O72WodNv5z5fTKrUlncnJuFt7jtsah4R1MRfMveQcq6KZhSidT/6aq4gw= X-Received: by 2002:a9d:1909:: with SMTP id j9mr2800728ota.283.1602096143527; Wed, 07 Oct 2020 11:42:23 -0700 (PDT) MIME-Version: 1.0 References: <20200122101654.20824-1-kalesh-anakkur.purayil@broadcom.com> <20200930123314.27669-1-kalesh-anakkur.purayil@broadcom.com> <20200930123314.27669-4-kalesh-anakkur.purayil@broadcom.com> In-Reply-To: From: Ajit Khaparde Date: Wed, 7 Oct 2020 11:42:07 -0700 Message-ID: To: Ferruh Yigit Cc: Kalesh Anakkur Purayil , Ophir Munk , "dev@dpdk.org" , NBU-Contact-Thomas Monjalon Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC PATCH v4 3/3] app/testpmd: handle device recovery event 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 Wed, Oct 7, 2020 at 2:37 AM Ferruh Yigit wrote: > > On 10/7/2020 5:46 AM, Kalesh Anakkur Purayil wrote: > > Hi Ophir, > > > > Thank you for the comments. I will address them in the next version. > > > > I will push these changes as Patches next time and not as an RFC. Hope that > > is OK. > > > > Regards, > > Kalesh > > > > On Tue, Oct 6, 2020 at 10:55 PM Ophir Munk wrote: > > > >> Hi Kalesh, > >> Please find a few comments. > >> The name you gave to the event (EVENT_RESET) is very close to an already > >> existing one: "EVENT_INTR_RESET". > >> But they are different. > >> EVENT_INTR_RESET originates from a port reset. It requires application > >> reaction. It is widely used. It is documented in *.rst files. > >> EVENT_RESET originates from FW error (or maybe any error). It requires no > >> application reaction (PMD manages by itself). It is not documented. > >> I therefore suggest renaming it (maybe EVENT_ERR_RECOVERING) and please > >> document it in *.rst files. > > +1 to renaming and documenting the event. > > And agree to proceed as regular patch instead of RFC. Ferruh, If/when the new version of patch is good, Can you pick the bnxt PMD patch along with the ethdev and testpmd patch? Let me know. > > > >> More comments below: > >> > >>> -----Original Message----- > >>> From: dev On Behalf Of Kalesh A P > >>> Sent: Wednesday, September 30, 2020 3:33 PM > >>> To: dev@dpdk.org > >>> Subject: [dpdk-dev] [RFC PATCH v4 3/3] app/testpmd: handle device > >> recovery > >>> event > >>> > >>> From: Kalesh AP > >>> > >>> Added code to handle device reset and recovery event in testpmd. > >>> This is an indication from the PMD that device has reset and recovered > >> error > >>> condition. > >>> > >>> Signed-off-by: Kalesh AP > >>> Reviewed-by: Ajit Kumar Khaparde > >>> --- > >>> app/test-pmd/testpmd.c | 6 +++++- > >>> 1 file changed, 5 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index > >>> fe6450c..1c8fb46 100644 > >>> --- a/app/test-pmd/testpmd.c > >>> +++ b/app/test-pmd/testpmd.c > >>> @@ -380,6 +380,8 @@ static const char * const eth_event_desc[] = { > >>> [RTE_ETH_EVENT_NEW] = "device probed", > >>> [RTE_ETH_EVENT_DESTROY] = "device released", > >>> [RTE_ETH_EVENT_FLOW_AGED] = "flow aged", > >>> + [RTE_ETH_EVENT_RESET] = "device reset", > >> > >> "device reset" is similar to the existing "reset" string. Can you suggest > >> a different one? Maybe "error under recovery" ? > >> > >>> + [RTE_ETH_EVENT_RECOVERED] = "device recovery", > >> > >> Wouldn't you prefer "device recovered" ? > >> > >>> [RTE_ETH_EVENT_MAX] = NULL, > >>> }; > >>> > >>> @@ -394,7 +396,9 @@ uint32_t event_print_mask = (UINT32_C(1) << > >>> RTE_ETH_EVENT_UNKNOWN) | > >>> (UINT32_C(1) << RTE_ETH_EVENT_IPSEC) | > >>> (UINT32_C(1) << RTE_ETH_EVENT_MACSEC) | > >>> (UINT32_C(1) << RTE_ETH_EVENT_INTR_RMV) | > >>> - (UINT32_C(1) << RTE_ETH_EVENT_FLOW_AGED); > >>> + (UINT32_C(1) << RTE_ETH_EVENT_FLOW_AGED) | > >>> + (UINT32_C(1) << RTE_ETH_EVENT_RESET) | > >>> + (UINT32_C(1) << RTE_ETH_EVENT_RECOVERED); > >>> /* > >>> * Decide if all memory are locked for performance. > >>> */ > >>> -- > >>> 2.10.1 > >> > >> > > >