From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerin Jacob Subject: Re: [PATCH v6 1/4] ethdev: add support of NIC reset Date: Wed, 12 Jul 2017 21:43:46 +0530 Message-ID: <20170712161344.GA2860@jerin> References: <1498817556-64379-1-git-send-email-wei.dai@intel.com> <1499681144-26031-1-git-send-email-wei.dai@intel.com> <1499681144-26031-2-git-send-email-wei.dai@intel.com> <20170710113506.GA17339@jerin> <49759EB36A64CF4892C1AFEC9231E8D650B60DC0@PGSMSX106.gar.corp.intel.com> <20170711051701.GA5637@jerin> <49759EB36A64CF4892C1AFEC9231E8D650B610E8@PGSMSX106.gar.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "thomas@monjalon.net" , "Lu, Wenzhuo" , "Ananyev, Konstantin" , "Wu, Jingjing" , "Xing, Beilei" , "dev@dpdk.org" To: "Dai, Wei" Return-path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0077.outbound.protection.outlook.com [104.47.32.77]) by dpdk.org (Postfix) with ESMTP id AD3B62E8B for ; Wed, 12 Jul 2017 18:14:05 +0200 (CEST) Content-Disposition: inline In-Reply-To: <49759EB36A64CF4892C1AFEC9231E8D650B610E8@PGSMSX106.gar.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" -----Original Message----- > Date: Tue, 11 Jul 2017 14:36:57 +0000 > From: "Dai, Wei" > To: Jerin Jacob > CC: "thomas@monjalon.net" , "Lu, Wenzhuo" > , "Ananyev, Konstantin" > , "Wu, Jingjing" , > "Xing, Beilei" , "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 > > Cc: thomas@monjalon.net; Lu, Wenzhuo ; > > Ananyev, Konstantin ; Wu, Jingjing > > ; Xing, Beilei ; > > 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" > > > To: Jerin Jacob > > > CC: "thomas@monjalon.net" , "Lu, Wenzhuo" > > > , "Ananyev, Konstantin" > > > , "Wu, Jingjing" > > > , "Xing, Beilei" , > > > "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. > > > > > > > > + *