[dpdk-dev,v8,5/5] doc: add description of the NIC reset API

Message ID 1500304503-41592-6-git-send-email-wei.dai@intel.com (mailing list archive)
State Superseded, archived
Headers

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

Wei Dai July 17, 2017, 3:15 p.m. UTC
  Signed-off-by: Wei Dai <wei.dai@intel.com>
---
 doc/guides/prog_guide/poll_mode_drv.rst | 40 +++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)
  

Comments

Remy Horton July 20, 2017, 1:22 p.m. UTC | #1
Unless the plan is for this patch to be squashed, ought to have a brief 
commit message..

On 17/07/2017 16:15, Wei Dai wrote:
> Signed-off-by: Wei Dai <wei.dai@intel.com>
> ---
>  doc/guides/prog_guide/poll_mode_drv.rst | 40 +++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)

Reviewed-by: Remy Horton <remy.horton@intel.com>


> +.. code-block:: c
> +
> +    int rte_eth_dev_reset(uint8_t port_id);
> +

Suggest following text:

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( ).


..Remy
  

Patch

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( ).