[dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset

Dai, Wei wei.dai at intel.com
Tue Jul 11 16:36:57 CEST 2017


> -----Original Message-----
> From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com]
> Sent: Tuesday, July 11, 2017 1:17 PM
> To: Dai, Wei <wei.dai at intel.com>
> Cc: thomas at monjalon.net; Lu, Wenzhuo <wenzhuo.lu at intel.com>;
> Ananyev, Konstantin <konstantin.ananyev at intel.com>; Wu, Jingjing
> <jingjing.wu at intel.com>; Xing, Beilei <beilei.xing at intel.com>;
> dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset
> 
> -----Original Message-----
> > Date: Tue, 11 Jul 2017 01:57:15 +0000
> > From: "Dai, Wei" <wei.dai at intel.com>
> > To: Jerin Jacob <jerin.jacob at caviumnetworks.com>
> > CC: "thomas at monjalon.net" <thomas at monjalon.net>, "Lu, Wenzhuo"
> >  <wenzhuo.lu at intel.com>, "Ananyev, Konstantin"
> >  <konstantin.ananyev at intel.com>, "Wu, Jingjing"
> > <jingjing.wu at intel.com>,  "Xing, Beilei" <beilei.xing at intel.com>,
> > "dev at dpdk.org" <dev at dpdk.org>
> > Subject: RE: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC
> > reset
> >
> >
> > > + * A DPDK application also can call this function to trigger an
> > > + initative
> > > + * port reset.
> >
> > When apart from the above use case? Even if it is above case, we should
> have some event to notify application to initiate the reset.Right? Without
> the event,  When or on what basics application needs to initiate reset?
> > [Wei: Indeed, until now we didn't see any use case which DPDK application
> initiative port reset itself.
> > The most usual case is that PF is working with kernel driver and VFs are
> working with DPDK PMD.
> > Some operations on kernel PF lead to a PF reset which causes its VF reset.
> > Anyway this new function provides a possibility for application to
> > trigger an initiative port reset.]
> 
> That's fine. The only concern part is when to call reset API from application.
> Can we say on RTE_ETH_EVENT_INTR_RESET event, application needs to
> call the reset API? I think, it is important to specify when application need to
> call this API, otherwise this api behavior will be tightly coupled with
> underneath PMD. Side effect is, a new, non portable PMD specific API.
> If a PMD wishes to fixup some overflow case(as an example), by invoking the
> reset API from the application BUT same case may not valid for another
> PMD hence it will create unexpected behavior from application based on the
> underneath PMD.
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 wants 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 ixgbe 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( ).

> 
> if RTE_ETH_EVENT_INTR_RESET event is not expected event to call the reset
> API then create a new event or if it needs to be called in
> RTE_ETH_EVENT_INTR_RESET then update the API documentation.
> 
Of course, when PMD wants to trigger a reset event, it can trigger other event other than
RTE_ETH_EVENT_INTR_RESET. So the application should know which the alternate event is.
This make application more complex. So it is suggested that only RTE_ETH_EVENT_INTR_RESET
can be used to trigger a port reset.

> >
> > > + *


More information about the dev mailing list