> -----Original Message----- > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] > Sent: Tuesday, July 11, 2017 1:17 PM > To: Dai, Wei <wei....@intel.com> > Cc: tho...@monjalon.net; Lu, Wenzhuo <wenzhuo...@intel.com>; > Ananyev, Konstantin <konstantin.anan...@intel.com>; Wu, Jingjing > <jingjing...@intel.com>; Xing, Beilei <beilei.x...@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....@intel.com> > > To: Jerin Jacob <jerin.ja...@caviumnetworks.com> > > CC: "tho...@monjalon.net" <tho...@monjalon.net>, "Lu, Wenzhuo" > > <wenzhuo...@intel.com>, "Ananyev, Konstantin" > > <konstantin.anan...@intel.com>, "Wu, Jingjing" > > <jingjing...@intel.com>, "Xing, Beilei" <beilei.x...@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( ).
> > 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. > > > > > + *
