From mboxrd@z Thu Jan 1 00:00:00 1970 From: Qi Zhang Subject: [RFC v2 0/2] ethdev: claim device reset as async Date: Mon, 10 Sep 2018 21:51:05 +0800 Message-ID: <20180910135107.6286-1-qi.z.zhang@intel.com> Cc: dev@dpdk.org, benjamin.h.shelton@intel.com, narender.vangati@intel.com, Qi Zhang To: thomas@monjalon.net, konstantin.ananyev@intel.com, declan.doherty@intel.com, ferruh.yigit@intel.com Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id AE0BD11A4 for ; Mon, 10 Sep 2018 15:50:15 +0200 (CEST) List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Device reset may have the dependency, for example, a VF reset expects PF ready, or a NIC function as a part of a SOC need to wait for other parts of the system be ready, these are time-consuming tasks and will block current thread. So we claimed rte_eth_dev_reset as an async API, that makes things easy for an application that what to reset the device from the interrupt thread since typically a RTE_ETH_EVENT_INTR_RESET handler is invoked in interrupt thread. rte_eth_dev_reset will spawn a new thread to call ops->dev_reset, once it is finished, it will raise the RTE_ETH_EVENT_RESET_COMPLETE event to notify the application. Application should not assume device reset is finished after rte_eth_dev_reset return, it should always wait for a RTE_ETH_EVENT_RESET_COMPLETE event and check the reset result. v2: - rte_eth_dev_reset will spawn a thread. Qi Zhang (2): ethdev: claim device reset as async testpmd: enable async device reset app/test-pmd/testpmd.c | 50 +++++++++++++++++++++++++++++++++++++++++- lib/librte_ethdev/rte_ethdev.c | 48 ++++++++++++++++++++++++++++++++++++++-- lib/librte_ethdev/rte_ethdev.h | 48 ++++++++++++++++++++++++---------------- 3 files changed, 124 insertions(+), 22 deletions(-) -- 2.13.6