From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id EF78B41DBB; Fri, 3 Mar 2023 00:31:04 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CF21040EE3; Fri, 3 Mar 2023 00:31:04 +0100 (CET) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on2048.outbound.protection.outlook.com [40.107.7.48]) by mails.dpdk.org (Postfix) with ESMTP id C84F540687 for ; Fri, 3 Mar 2023 00:31:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SDETMTHusgibzt3ABve4HD2dS/01JtPdWSfnnRywuBc=; b=h2rG6KAW9p7wXEVOrd1r1C5eSWkp+l3fjpnw3Pxj/MfwDNJgNCGON/2e6sxc/MH7JcI+aVvsfaLR+I0cK87I1E0TmJruTa+8i9WwSzNw3V7jfPtgmgC3koAFiNCqCdlMvfsU7njVleRPotHGZYmQS5mHeOhd4HHC573cOIWN2QY= Received: from DB6P192CA0022.EURP192.PROD.OUTLOOK.COM (2603:10a6:4:b8::32) by PA4PR08MB6286.eurprd08.prod.outlook.com (2603:10a6:102:f2::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.20; Thu, 2 Mar 2023 23:31:00 +0000 Received: from DBAEUR03FT026.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:b8:cafe::93) by DB6P192CA0022.outlook.office365.com (2603:10a6:4:b8::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.21 via Frontend Transport; Thu, 2 Mar 2023 23:31:00 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DBAEUR03FT026.mail.protection.outlook.com (100.127.142.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.19 via Frontend Transport; Thu, 2 Mar 2023 23:31:00 +0000 Received: ("Tessian outbound 55ffa3012b8f:v135"); Thu, 02 Mar 2023 23:31:00 +0000 X-CR-MTA-TID: 64aa7808 Received: from d0738b83d29c.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 62E36AF4-0EEF-467B-9411-7D7620625B16.1; Thu, 02 Mar 2023 23:30:53 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id d0738b83d29c.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 02 Mar 2023 23:30:53 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nIgebDcpeXxMbOJeOpDJBq9yQAnchVLGuwF6z+dx2Q7+CFRIGYKq08xmuCAQs+QHZTzErpOBHRDtueXvVFIL5cZ3q/95PSilTr7euthk71zTL3HovWdgOTczWSLLAKygmihRFAp2QV0B7zPCtstLL+avsVslxI4JZ0k1JzRNY+qYetbcAeZn6zQYO7Bb8U/KXO65fUujQQ5qWY7rucNjjlzeJMawY6l7xxYECjxv9X8ZHiYCEhRBiKYxcxK8SoiTwWHGFtVB7bng6B5ELJKPXoHXAyMTROOnR0sGCQubIYhZjHMSnvDOpFufHBM/HFIHoShyG7dUi+XxJDkrvRMDUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SDETMTHusgibzt3ABve4HD2dS/01JtPdWSfnnRywuBc=; b=dsQ5CHJnc6V7JHCPkd1ojhoahBjuI1eSoaUxgO8rsOevZZmOXn7ZKjNaIQJ4ieqcdtiWdfhRwZlYGKjNrjvoZyIF9C0exyEfIFHstzzRNdjY8jCi/FgV1cq/ogjpkcc7V2Ol7WYWZd0uz7NFcyZW8RmLUmQmNXjwYBxm4zv6Bga2Cqb4uHQr2TDdKj+82nOZV3EzOslQNjf9OrQDfgm1MoMVpPKk5oLAhi7hXw3G0iymZ4vMlu4z7EqoP62l7OJlF42Ztjk7lvP81LCL98sg/iSJ0sGIDbUQEKTdQNA6z0fPoxAtBZkyVHDIKfpMG5wJPylUY0TG2joNrbBAGipe6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SDETMTHusgibzt3ABve4HD2dS/01JtPdWSfnnRywuBc=; b=h2rG6KAW9p7wXEVOrd1r1C5eSWkp+l3fjpnw3Pxj/MfwDNJgNCGON/2e6sxc/MH7JcI+aVvsfaLR+I0cK87I1E0TmJruTa+8i9WwSzNw3V7jfPtgmgC3koAFiNCqCdlMvfsU7njVleRPotHGZYmQS5mHeOhd4HHC573cOIWN2QY= Received: from DBAPR08MB5814.eurprd08.prod.outlook.com (2603:10a6:10:1b1::6) by VI1PR08MB10274.eurprd08.prod.outlook.com (2603:10a6:800:1be::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6156.18; Thu, 2 Mar 2023 23:30:49 +0000 Received: from DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::910e:e35f:b1eb:ae9]) by DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::910e:e35f:b1eb:ae9%4]) with mapi id 15.20.6156.019; Thu, 2 Mar 2023 23:30:49 +0000 From: Honnappa Nagarahalli To: Chengwen Feng , "thomas@monjalon.net" , "ferruh.yigit@amd.com" , "konstantin.ananyev@huawei.com" , Andrew Rybchenko , Kalesh AP , "Ajit Khaparde (ajit.khaparde@broadcom.com)" CC: "dev@dpdk.org" , nd , nd Subject: RE: [PATCH 1/5] ethdev: fix race-condition of proactive error handling mode Thread-Topic: [PATCH 1/5] ethdev: fix race-condition of proactive error handling mode Thread-Index: AQHZS+vQExpR5AcJek+fR6H0lQR6ea7oHPFA Date: Thu, 2 Mar 2023 23:30:48 +0000 Message-ID: References: <20230301030610.49468-1-fengchengwen@huawei.com> <20230301030610.49468-2-fengchengwen@huawei.com> In-Reply-To: <20230301030610.49468-2-fengchengwen@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: FC8ED5BE8294094C8341DEA9BE3A5A77.0 x-checkrecipientchecked: true Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5814:EE_|VI1PR08MB10274:EE_|DBAEUR03FT026:EE_|PA4PR08MB6286:EE_ X-MS-Office365-Filtering-Correlation-Id: fa0766fc-b0bb-4740-9148-08db1b762e7a x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 0ImTelw14ys0hn4Ucc9/j+MW9yotEmh5xeP2pyKqHp11IYru7yCWFyBdXgvP8V34aW1lCizw30Usy1gvzGbVb9DNuDKrx8k7jxv84nXilYCeEVf9KIV37isCxj6NC5FM66i8dqJ5BZf1julgmXijgmaQTTG5HUjPC5Gm+AL2lVX2R9GC9KtjhMrmsibEBrWWQ2IWvrtqMQwk99/xf9VXYJZyceN67G0j35ZSkYJpcMJ4sV+vK9GEriuowwQ/akYViN7FR31uTA/jTakLqT+hC7KBHGJig9TdWxpPt2ZmsHtirKmKYQBx28IAQMV899ts+tgI3JJazcQPh78lz+xZWqm0IAGtOUoxZAAklUftKE1IAZJCyyYo4tBUYQNo1y/0Sfd6aoYhAUwNr7BnVwIF7kvvcqrYKpfZHnzZYKlWXADyiYjURDx4kNVYjqTT3v3KfNsnWVEvEUCnipmkQrwtHlvDrwTgZmUjmN5FBYKM0ZbVRANDAirEdBvGVxrzIxvUkT0A1coOF+G4j4MndXjqjruNUoIhN55HptYm9fwIX8XvGD93ESR/ZLBYb7pJpxLr3i15s3C2DW2EBoxugXaOgANkHqWBwJ6vrgU9LDBVcYEiX1ipqgYxDBn/DhzHizboGncwvUD3bsTuvdFz4Y8U95KCG+jydAp8pAcqZhIUxHI8Gghcq4GP5TFz10VFtvDv X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR08MB5814.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(136003)(346002)(39860400002)(366004)(396003)(376002)(451199018)(83380400001)(33656002)(55016003)(53546011)(122000001)(38100700002)(5660300002)(52536014)(478600001)(8936002)(66556008)(86362001)(38070700005)(71200400001)(26005)(9686003)(186003)(76116006)(6506007)(966005)(64756008)(8676002)(66446008)(7696005)(66946007)(66476007)(2906002)(4326008)(316002)(54906003)(41300700001)(110136005); DIR:OUT; SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB10274 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DBAEUR03FT026.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: d6fd8138-6449-4115-c305-08db1b7627b8 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: AEfXiMbbCKAWYdeMgpJ12SB9Y42gHfRd8UP6u//t7a2uhJ0UaofleQV/Ekst3MjCnmsBCJ972lWQTzNwj16kGmTSFBfeJLBpQbeS7mocADZiF36wEVz+1USoqf65M5EesLb7U+qIsvNa03C4eqvJtFcTY2lxortPdhdGQihNQIiMrDmI0NRaRUE3Gt2tZwqyClv3jl8B/QcwIb9WST3IZLIyIBxZgyEeErXUVwKa0TENuw3MyETtYAzDHjT9MvAu9F/bnd6wVVxTisz+b5w1f8VMy0Pz2VMg1azMmcW5MNw++T4GJdt7m+E07eHNDE3/INoAEMqOIMkzaYemMZxwFLe20LNsigGWTncItHhYr+Prgzk/FMGiQgEARR2t3BbQDI5ojFJvHqPI1ycySnrgkCdNFUq3BDyJTeKUCJI3i6JkXFxMaVaudWk3bOnQrK894vnzlBcklMEY4PpKW9Z2bfvIiEYdJpf6BcvJfeBlyRXSTm+1KaTTlhu8seCbwAb5kYi6HN0eg71n5mCX+DrS/jvb4Ea9+ITgefWV0voT8O5IbSwKgG8bS8t1MjVyqPG/r++QerLmbwXircjQLLKrHuFNSmf2aAiXVi06IL0QiekLy/5ijz0KUWOKI1MwwgbYeD7RCT4YZfhLp8O3+xsNiGXhFfNvuU9sJoovQeaxc4IAEDNBvTuzBaU4DxMx8ni/ X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230025)(4636009)(346002)(39860400002)(396003)(136003)(376002)(451199018)(46966006)(40470700004)(36840700001)(5660300002)(41300700001)(52536014)(8936002)(2906002)(70586007)(4326008)(8676002)(70206006)(82310400005)(54906003)(83380400001)(316002)(110136005)(40460700003)(7696005)(478600001)(966005)(53546011)(33656002)(6506007)(336012)(55016003)(47076005)(86362001)(40480700001)(9686003)(81166007)(82740400003)(26005)(186003)(356005)(36860700001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2023 23:31:00.2776 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fa0766fc-b0bb-4740-9148-08db1b762e7a X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DBAEUR03FT026.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6286 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > -----Original Message----- > From: Chengwen Feng > Sent: Tuesday, February 28, 2023 9:06 PM > To: thomas@monjalon.net; ferruh.yigit@amd.com; > konstantin.ananyev@huawei.com; Andrew Rybchenko > ; Kalesh AP anakkur.purayil@broadcom.com>; Ajit Khaparde > (ajit.khaparde@broadcom.com) > Cc: dev@dpdk.org > Subject: [PATCH 1/5] ethdev: fix race-condition of proactive error handli= ng > mode >=20 > In the proactive error handling mode, the PMD will set the data path poin= ters to > dummy functions and then try recovery, in this period the application may= still > invoking data path API. This will introduce a race-condition with data pa= th which > may lead to crash [1]. >=20 > Although the PMD added delay after setting data path pointers to cover th= e > above race-condition, it reduces the probability, but it doesn't solve th= e > problem. >=20 > To solve the race-condition problem fundamentally, the following requirem= ents > are added: > 1. The PMD should set the data path pointers to dummy functions after > report RTE_ETH_EVENT_ERR_RECOVERING event. Do you mean to say, PMD should set the data path pointers after calling the= call back function? The PMD is running in the context of multiple EAL threads. How do these thr= eads synchronize such that only one thread sets these data pointers? > 2. The application should stop data path API invocation when process > the RTE_ETH_EVENT_ERR_RECOVERING event. Any thoughts on how an application can do this? > 3. The PMD should set the data path pointers to valid functions before > report RTE_ETH_EVENT_RECOVERY_SUCCESS event. > 4. The application should enable data path API invocation when process > the RTE_ETH_EVENT_RECOVERY_SUCCESS event. Do you mean to say that the application should not call the datapath APIs w= hile the PMD is running the recovery process? >=20 > Also, this patch introduce a driver internal function rte_eth_fp_ops_setu= p > which used as an help function for PMD. >=20 > [1] > http://patchwork.dpdk.org/project/dpdk/patch/20230220060839.1267349-2- > ashok.k.kaladi@intel.com/ >=20 > Fixes: eb0d471a8941 ("ethdev: add proactive error handling mode") > Cc: stable@dpdk.org >=20 > Signed-off-by: Chengwen Feng > --- > doc/guides/prog_guide/poll_mode_drv.rst | 20 +++++++--------- > lib/ethdev/ethdev_driver.c | 8 +++++++ > lib/ethdev/ethdev_driver.h | 10 ++++++++ > lib/ethdev/rte_ethdev.h | 32 +++++++++++++++---------- > lib/ethdev/version.map | 1 + > 5 files changed, 46 insertions(+), 25 deletions(-) >=20 > diff --git a/doc/guides/prog_guide/poll_mode_drv.rst > b/doc/guides/prog_guide/poll_mode_drv.rst > index c145a9066c..e380ff135a 100644 > --- a/doc/guides/prog_guide/poll_mode_drv.rst > +++ b/doc/guides/prog_guide/poll_mode_drv.rst > @@ -638,14 +638,9 @@ different from the application invokes recovery in > PASSIVE mode, the PMD automatically recovers from error in PROACTIVE > mode, and only a small amount of work is required for the application. >=20 > -During error detection and automatic recovery, -the PMD sets the data pa= th > pointers to dummy functions -(which will prevent the crash), -and also ma= ke > sure the control path operations fail with a return code ``-EBUSY``. > - > -Because the PMD recovers automatically, -the application can only sense = that > the data flow is disconnected for a while -and the control API returns an= error in > this period. > +During error detection and automatic recovery, the PMD sets the data > +path pointers to dummy functions and also make sure the control path > +operations failed with a return code ``-EBUSY``. >=20 > In order to sense the error happening/recovering, as well as to restore= some > additional configuration, @@ -653,9 +648,9 @@ three events are available: >=20 > ``RTE_ETH_EVENT_ERR_RECOVERING`` > Notify the application that an error is detected > - and the recovery is being started. > + and the recovery is about to start. > Upon receiving the event, the application should not invoke > - any control path function until receiving > + any control and data path API until receiving > ``RTE_ETH_EVENT_RECOVERY_SUCCESS`` or > ``RTE_ETH_EVENT_RECOVERY_FAILED`` event. >=20 > .. note:: > @@ -666,8 +661,9 @@ three events are available: >=20 > ``RTE_ETH_EVENT_RECOVERY_SUCCESS`` > Notify the application that the recovery from error is successful, > - the PMD already re-configures the port, > - and the effect is the same as a restart operation. > + the PMD already re-configures the port. > + The application should restore some additional configuration, and the= n What is the additional configuration? Is this specific to each NIC/PMD? I thought, this is an auto recovery process and the application does not re= quire to reconfigure anything. If the application has to restore the config= uration, how does auto recovery differ from typical recovery process? > + enable data path API invocation. >=20 > ``RTE_ETH_EVENT_RECOVERY_FAILED`` > Notify the application that the recovery from error failed, diff --gi= t > a/lib/ethdev/ethdev_driver.c b/lib/ethdev/ethdev_driver.c index > 0be1e8ca04..f994653fe9 100644 > --- a/lib/ethdev/ethdev_driver.c > +++ b/lib/ethdev/ethdev_driver.c > @@ -515,6 +515,14 @@ rte_eth_dma_zone_free(const struct rte_eth_dev > *dev, const char *ring_name, > return rc; > } >=20 > +void > +rte_eth_fp_ops_setup(struct rte_eth_dev *dev) { > + if (dev =3D=3D NULL) > + return; > + eth_dev_fp_ops_setup(rte_eth_fp_ops + dev->data->port_id, dev); } > + > const struct rte_memzone * > rte_eth_dma_zone_reserve(const struct rte_eth_dev *dev, const char > *ring_name, > uint16_t queue_id, size_t size, unsigned int align, diff - > -git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h index > 2c9d615fb5..0d964d1f67 100644 > --- a/lib/ethdev/ethdev_driver.h > +++ b/lib/ethdev/ethdev_driver.h > @@ -1621,6 +1621,16 @@ int > rte_eth_dma_zone_free(const struct rte_eth_dev *eth_dev, const char > *name, > uint16_t queue_id); >=20 > +/** > + * @internal > + * Setup eth fast-path API to ethdev values. > + * > + * @param dev > + * Pointer to struct rte_eth_dev. > + */ > +__rte_internal > +void rte_eth_fp_ops_setup(struct rte_eth_dev *dev); > + > /** > * @internal > * Atomically set the link status for the specific device. > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index > 049641d57c..44ee7229c1 100644 > --- a/lib/ethdev/rte_ethdev.h > +++ b/lib/ethdev/rte_ethdev.h > @@ -3944,25 +3944,28 @@ enum rte_eth_event_type { > */ > RTE_ETH_EVENT_RX_AVAIL_THRESH, > /** Port recovering from a hardware or firmware error. > - * If PMD supports proactive error recovery, > - * it should trigger this event to notify application > - * that it detected an error and the recovery is being started. > - * Upon receiving the event, the application should not invoke any > control path API > - * (such as rte_eth_dev_configure/rte_eth_dev_stop...) until receiving > - * RTE_ETH_EVENT_RECOVERY_SUCCESS or > RTE_ETH_EVENT_RECOVERY_FAILED event. > - * The PMD will set the data path pointers to dummy functions, > - * and re-set the data path pointers to non-dummy functions > - * before reporting RTE_ETH_EVENT_RECOVERY_SUCCESS event. > - * It means that the application cannot send or receive any packets > - * during this period. > + * > + * If PMD supports proactive error recovery, it should trigger this > + * event to notify application that it detected an error and the > + * recovery is about to start. > + * > + * Upon receiving the event, the application should not invoke any > + * control and data path API until receiving > + * RTE_ETH_EVENT_RECOVERY_SUCCESS or > RTE_ETH_EVENT_RECOVERY_FAILED > + * event. > + * > + * Once this event is reported, the PMD will set the data path pointers > + * to dummy functions, and re-set the data path pointers to valid > + * functions before reporting RTE_ETH_EVENT_RECOVERY_SUCCESS > event. Why do we need to set the data path pointers to dummy functions if the appl= ication is restricted from invoking any control and data path APIs till the= recovery process is completed? > + * > * @note Before the PMD reports the recovery result, > * the PMD may report the RTE_ETH_EVENT_ERR_RECOVERING event > again, > * because a larger error may occur during the recovery. > */ > RTE_ETH_EVENT_ERR_RECOVERING, I understand this is not a change in this patch. But, just wondering, what = is the purpose of this? How is the application supposed to use this? > /** Port recovers successfully from the error. > - * The PMD already re-configured the port, > - * and the effect is the same as a restart operation. > + * > + * The PMD already re-configured the port: > * a) The following operation will be retained: (alphabetically) > * - DCB configuration > * - FEC configuration > @@ -3989,6 +3992,9 @@ enum rte_eth_event_type { > * (@see RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP) > * c) Any other configuration will not be stored > * and will need to be re-configured. > + * > + * The application should restore some additional configuration > + * (see above case b/c), and then enable data path API invocation. > */ > RTE_ETH_EVENT_RECOVERY_SUCCESS, > /** Port recovery failed. > diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map index > 357d1a88c0..c273e0bdae 100644 > --- a/lib/ethdev/version.map > +++ b/lib/ethdev/version.map > @@ -320,6 +320,7 @@ INTERNAL { > rte_eth_devices; > rte_eth_dma_zone_free; > rte_eth_dma_zone_reserve; > + rte_eth_fp_ops_setup; > rte_eth_hairpin_queue_peer_bind; > rte_eth_hairpin_queue_peer_unbind; > rte_eth_hairpin_queue_peer_update; > -- > 2.17.1