From patchwork Sun Jul 23 09:15:13 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wei Dai X-Patchwork-Id: 27109 X-Patchwork-Delegate: thomas@monjalon.net Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id 0A0B256A1; Sun, 23 Jul 2017 11:26:41 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 6D0C6325D for ; Sun, 23 Jul 2017 11:26:33 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2017 02:26:32 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.40,400,1496127600"; d="scan'208"; a="1175570327" Received: from dpdk6.bj.intel.com ([172.16.182.87]) by fmsmga001.fm.intel.com with ESMTP; 23 Jul 2017 02:26:29 -0700 From: Wei Dai To: thomas@monjalon.net, wenzhuo.lu@intel.com, konstantin.ananyev@intel.com, jingjing.wu@intel.com, beilei.xing@intel.com Cc: dev@dpdk.org, Wei Dai Date: Sun, 23 Jul 2017 17:15:13 +0800 Message-Id: <1500801313-25429-6-git-send-email-wei.dai@intel.com> X-Mailer: git-send-email 2.7.5 In-Reply-To: <1500801313-25429-1-git-send-email-wei.dai@intel.com> References: <1500304503-41592-1-git-send-email-wei.dai@intel.com> <1500801313-25429-1-git-send-email-wei.dai@intel.com> Subject: [dpdk-dev] [PATCH v9 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" This patch add the description of NIC reset API in doc/guides/prog_guide/poll_mode_drv.rst . It explains why this API is needed, when it should be called and some noticeable information. Signed-off-by: Wei Dai Reviewed-by: Remy Horton --- doc/guides/prog_guide/poll_mode_drv.rst | 41 +++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/doc/guides/prog_guide/poll_mode_drv.rst b/doc/guides/prog_guide/poll_mode_drv.rst index 1ac8f7e..7c95b3e 100644 --- a/doc/guides/prog_guide/poll_mode_drv.rst +++ b/doc/guides/prog_guide/poll_mode_drv.rst @@ -536,3 +536,44 @@ 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 has to be reset passively. For example when a PF is +reset, all its VFs should also be reset by the application to make them +consistent with the PF. A DPDK application also can call this function +to trigger a port reset. Normally, a DPDK application would invokes this +function when an RTE_ETH_EVENT_INTR_RESET event is detected. + +It is the duty of the PMD to trigger RTE_ETH_EVENT_INTR_RESET events and +the application should register a callback function to handle these +events. When a PMD needs to trigger a reset, it can trigger an +RTE_ETH_EVENT_INTR_RESET event. On receiving an RTE_ETH_EVENT_INTR_RESET +event, applications can handle it as follows: Stop working queues, stop +calling Rx and Tx functions, and then call rte_eth_dev_reset( ). For +thread safety all these operations should be called from the same thread. + +For example when PF is reset, the PF sends a message to notify VFs of +this event and also trigger an interrupt to VFs. Then in the interrupt +service routine the VFs detects this notification message and calls +_rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_INTR_RESET, NULL, +NULL). This means that a PF reset triggers an RTE_ETH_EVENT_INTR_RESET +event within VFs. The function _rte_eth_dev_callback_process( ) will +call the registered callback function. The callback function can trigger +the application to handle all operations the VF reset requires including +stopping Rx/Tx queues and calling rte_eth_dev_reset(). + +The rte_eth_dev_reset( ) itself is a generic function which only does +some hardware reset operations through calling dev_unint() and +dev_init(), and itself does not handle synchronization, which is handled +by application. + +The PMD itself should not call rte_eth_dev_reset( ). The PMD can trigger +the application to handle reset event. It is duty of application to +handle all synchronization before it calls rte_eth_dev_reset( ). +