From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 935C42C6A for ; Tue, 11 Jul 2017 16:37:06 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP; 11 Jul 2017 07:37:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,347,1496127600"; d="scan'208";a="1171148799" Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86]) by fmsmga001.fm.intel.com with ESMTP; 11 Jul 2017 07:36:59 -0700 Received: from pgsmsx106.gar.corp.intel.com ([169.254.9.158]) by KMSMSX151.gar.corp.intel.com ([169.254.10.60]) with mapi id 14.03.0319.002; Tue, 11 Jul 2017 22:36:58 +0800 From: "Dai, Wei" To: Jerin Jacob CC: "thomas@monjalon.net" , "Lu, Wenzhuo" , "Ananyev, Konstantin" , "Wu, Jingjing" , "Xing, Beilei" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset Thread-Index: AQHS+WWa1PmUN361mUavg2CqZl6Kd6JMaEGAgAFxpSD//7cNAIABFOFg Date: Tue, 11 Jul 2017 14:36:57 +0000 Message-ID: <49759EB36A64CF4892C1AFEC9231E8D650B610E8@PGSMSX106.gar.corp.intel.com> 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> In-Reply-To: <20170711051701.GA5637@jerin> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [172.30.20.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 14:37:07 -0000 > -----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 >=20 > -----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? Withou= t > 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 applicati= on > initiative port reset itself. > > The most usual case is that PF is working with kernel driver and VFs ar= e > working with DPDK PMD. > > Some operations on kernel PF lead to a PF reset which causes its VF res= et. > > Anyway this new function provides a possibility for application to > > trigger an initiative port reset.] >=20 > That's fine. The only concern part is when to call reset API from applica= tion. > 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 t= he > reset API from the application BUT same case may not valid for another > PMD hence it will create unexpected behavior from application based on th= e > 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.=20 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=20 and then call rte_eth_dev_reset( ). For thread safety, all these controlling operations had better be made in s= ame thread. For example, when ixgbe PF is reset, PF send a message to notify VF this ev= ent and=20 also trigger an interrupt to VF. And then in the interrupt service routine= DPDK VF=20 detect this notification message and calls=20 _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 call= back function. The callback function can trigger application to handle all operations of V= F reset including something like stopping working Rx/Tx queues and call this rte_eth_dev_rese= t(). 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 applicatio= n to handle reset event. It is duty of application to handle all synchronization befort it calls rte= _eth_dev_reset( ). >=20 > 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. >=20 Of course, when PMD wants to trigger a reset event, it can trigger other ev= ent other than RTE_ETH_EVENT_INTR_RESET. So the application should know which the alternat= e event is. This make application more complex. So it is suggested that only RTE_ETH_EV= ENT_INTR_RESET can be used to trigger a port reset. > > > > > + *