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 C44E5A04B5; Wed, 30 Sep 2020 10:35:42 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A8E7A1D6FE; Wed, 30 Sep 2020 10:35:41 +0200 (CEST) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by dpdk.org (Postfix) with ESMTP id 4C75C1D68A for ; Wed, 30 Sep 2020 10:35:39 +0200 (CEST) Received: by mail-il1-f196.google.com with SMTP id l16so779376ilt.13 for ; Wed, 30 Sep 2020 01:35:39 -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=NRdpOj+T3VySF3++Z5/8hhPL5g0S1lPztIi6zfbgsTM=; b=Nc+pDVwlhZ7E708sW3bSEVlXtX36formYxzMj3hpkbX01lhlYFcaReX7MZaiuiwoxx X5uBDkoIKJeXe5IeyFjHISeWhQo+uAkOp1FrkbrpgBKiXj3PUfHU79HsQmV5D3gvPRSe MpzXpgNAni0UwvkMivkKrmxbCz2ZRTrMYyZmw= 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=NRdpOj+T3VySF3++Z5/8hhPL5g0S1lPztIi6zfbgsTM=; b=bbmU4Q8Sc7f3ri+5mjp1ImUb1enZA8M1W3xDaHYkWL+y2MQ9EThUVkrDlyl//OBTuq liG0k8DY4IDpbVOuOzzQZKDZ78tE/EFpfMtYVGKR81zxa8qAKJu1jcFkXSSB5n4Cde7I jdp26FCrUiF4+7cJK8SFOu/dKCve1ROno2S/FiQ7gSBcPGXqPQxJCs/CxMuXMiiDYjGg LA2NzixTtUKm9KD8Ot5eIUQNlirzYlIWWCWso2wiuK8+aYNbNYV5uSpUozNMu5AUNCKm vdaUTxLpY+iBWsjARQNSXXzsnqu+aMrO2+42ooDk0MQFY7I3/tmVbbwj8MzjoIhFHtdu /SIA== X-Gm-Message-State: AOAM530dDZpzNfmCdkNeAbxnZf+FA+imLIhqZoju4KClZseCi62muCiC Od0h8l6YeuW8zGRw87PMsKSB6+TIPc4XoRm1CNe+bQ== X-Google-Smtp-Source: ABdhPJyQv0RazftwbVYSuAsi57QTqs9Lpcj9M3H0gWqlBPRDzP9AizjV7yFtMVD0CBx5NS24cn0MFwxciEfTtwgTUMU= X-Received: by 2002:a92:d091:: with SMTP id h17mr1137296ilh.264.1601454937351; Wed, 30 Sep 2020 01:35:37 -0700 (PDT) MIME-Version: 1.0 References: <20200122101654.20824-1-kalesh-anakkur.purayil@broadcom.com> <20200930071258.22457-1-kalesh-anakkur.purayil@broadcom.com> <20200930071258.22457-2-kalesh-anakkur.purayil@broadcom.com> <3129125.UTyNnJLbx8@thomas> In-Reply-To: <3129125.UTyNnJLbx8@thomas> From: Kalesh Anakkur Purayil Date: Wed, 30 Sep 2020 14:05:26 +0530 Message-ID: To: Thomas Monjalon Cc: dev@dpdk.org, "Yigit, Ferruh" , Ajit Kumar Khaparde , arybchenko@solarflare.com Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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" Hi Thomas, Please see my response inline. Regards, Kalesh On Wed, Sep 30, 2020 at 1:21 PM Thomas Monjalon wrote: > Hi, > > Please use --cc-cmd devtools/get-maintainer.sh so all relevant > maintainers are Cc'ed. Adding Andrew. > [Kalesh]: Thank you. Sure, I will follow next time. > > > 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? -- Regards, Kalesh A P