Re: [PATCH v6 1/4] ethdev: add support of NIC reset

[Jerin Jacob <jerin.jacob@caviumnetworks.com>]

-----Original Message-----
> Date: Tue, 11 Jul 2017 14:36:57 +0000
> From: "Dai, Wei" <wei.dai@intel.com>
> To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> CC: "thomas@monjalon.net" <thomas@monjalon.net>, "Lu, Wenzhuo"
>  <wenzhuo.lu@intel.com>, "Ananyev, Konstantin"
>  <konstantin.ananyev@intel.com>, "Wu, Jingjing" <jingjing.wu@intel.com>,
>  "Xing, Beilei" <beilei.xing@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
> Subject: RE: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset
> 
> > -----Original Message-----
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > Sent: Tuesday, July 11, 2017 1:17 PM
> > To: Dai, Wei <wei.dai@intel.com>
> > Cc: thomas@monjalon.net; Lu, Wenzhuo <wenzhuo.lu@intel.com>;
> > Ananyev, Konstantin <konstantin.ananyev@intel.com>; Wu, Jingjing
> > <jingjing.wu@intel.com>; Xing, Beilei <beilei.xing@intel.com>;
> > dev@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@intel.com>
> > > To: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > > CC: "thomas@monjalon.net" <thomas@monjalon.net>, "Lu, Wenzhuo"
> > >  <wenzhuo.lu@intel.com>, "Ananyev, Konstantin"
> > >  <konstantin.ananyev@intel.com>, "Wu, Jingjing"
> > > <jingjing.wu@intel.com>,  "Xing, Beilei" <beilei.xing@intel.com>,
> > > "dev@dpdk.org" <dev@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( ).

No disagreement on the expected behavior.


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

Yes. I suggest to add this info on documentation. ie "application invokes the
reset API on RTE_ETH_EVENT_INTR_RESET event". That will answer "when"
application need to invoke this API.

> 
> > >
> > > > + *