From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id F0E4B5905 for ; Mon, 17 Jul 2017 17:26:06 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP; 17 Jul 2017 08:26:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,374,1496127600"; d="scan'208";a="879734897" Received: from dpdk6.bj.intel.com ([172.16.182.87]) by FMSMGA003.fm.intel.com with ESMTP; 17 Jul 2017 08:26:04 -0700 From: Wei Dai To: thomas@monjalon.net, wenzhuo.lu@intel.com, konstantin.ananyev@intel.com, beilei.xing@intel.com, jingjing.wu@intel.com, john.mcnamara@intel.com Cc: dev@dpdk.org, Wei Dai Date: Mon, 17 Jul 2017 23:15:03 +0800 Message-Id: <1500304503-41592-6-git-send-email-wei.dai@intel.com> X-Mailer: git-send-email 2.7.5 In-Reply-To: <1500304503-41592-1-git-send-email-wei.dai@intel.com> References: <1499961223-45281-1-git-send-email-wei.dai@intel.com> <1500304503-41592-1-git-send-email-wei.dai@intel.com> Subject: [dpdk-dev] [PATCH v8 5/5] doc: add description of the NIC reset API 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: , X-List-Received-Date: Mon, 17 Jul 2017 15:26:08 -0000 Signed-off-by: Wei Dai --- doc/guides/prog_guide/poll_mode_drv.rst | 40 +++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/doc/guides/prog_guide/poll_mode_drv.rst b/doc/guides/prog_guide/poll_mode_drv.rst index 4987f70..60518fc 100644 --- a/doc/guides/prog_guide/poll_mode_drv.rst +++ b/doc/guides/prog_guide/poll_mode_drv.rst @@ -525,3 +525,43 @@ call. As an end result, the application is able to achieve its goal of monitoring a single statistic ("rx_errors" in this case), and if that shows packets being dropped, it can easily retrieve a "set" of statistics using the IDs array parameter to ``rte_eth_xstats_get_by_id`` function. + +NIC Reset API +~~~~~~~~~~~~~ + +.. code-block:: c + + int rte_eth_dev_reset(uint8_t port_id); + +Sometimes a port have to be reset passively. For example a PF is reset, all its +VFs should also be reset by application itself to align with the PF. A DPDK +application also can call this function to trigger an initative port reset. + +Normally, a DPDK application can invake this function when +RTE_ETH_EVENT_INTR_RESET event is detected. + +It is duty of PMD to trigger RTE_ETH_EVENT_INTR_RESET event and application +should also register some callback function to handle this event. +When PMD needs to trigger a reset, it can trigger RTE_ETH_EVENT_INTR_RESET. +On the received event of RTE_ETH_EVENT_INTR_RESET, application can begin to +handle it: stop working queues, make rx and tx function not be called and +then call rte_eth_dev_reset( ).For thread safety, all these controlling +operations had better be made in same thread. + +For example, when PF is reset, PF send a message to notify VF this event and +also trigger an interrupt to VF. And then in the interrupt service routine +DPDK VF detect this notification message and calls +_rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_INTR_RESET, NULL, NULL). +So it means that PF reset trigger RTE_ETH_EVENT_INTR_RESET event in VF. +The function _rte_eth_dev_callback_process( ) will call the registered +callback function. The callback function can trigger application to handle +all operations of VF reset including something like stopping working Rx/Tx +queues and call this rte_eth_dev_reset(). + +The rte_eth_dev_reset( ) itself is generic function which only does some HW +reset operations through calling dev_unint() and dev_init(). And itself doesn't +handle above synchronization which is handled by application. + +PMD itself should not call rte_eth_dev_reset( ). PMD can trigger application to +handle reset event. It is duty of application to handle all synchronization +befort it calls rte_eth_dev_reset( ). -- 2.7.5