From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 1BB2FADC3 for ; Wed, 22 Jun 2016 08:42:48 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 21 Jun 2016 23:42:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,508,1459839600"; d="scan'208";a="980918814" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga001.jf.intel.com with ESMTP; 21 Jun 2016 23:42:48 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 21 Jun 2016 23:42:47 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 21 Jun 2016 23:42:46 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.147]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.107]) with mapi id 14.03.0248.002; Wed, 22 Jun 2016 14:42:44 +0800 From: "Lu, Wenzhuo" To: Jerin Jacob CC: "Ananyev, Konstantin" , Stephen Hemminger , "dev@dpdk.org" , "Richardson, Bruce" , "Chen, Jing D" , "Liang, Cunming" , "Wu, Jingjing" , "Zhang, Helin" , "thomas.monjalon@6wind.com" Thread-Topic: [dpdk-dev] [PATCH v6 1/4] lib/librte_ether: support device reset Thread-Index: AQHRyrx6NqZsK6LoQ0Kr0EDRoXtySZ/xjKGAgAB2MwCAAMH0gIAAqwkw//+UC4CAAIsykP//irIAgAAIkQCAABmdAIAAJRoAgAAFmQCAAAkYgIAAB1CAgAE5dBD//5INgAASMuVg//+JcoD//22SwIAAsrIA//9zMjA= Date: Wed, 22 Jun 2016 06:42:43 +0000 Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC09090348987B@shsmsx102.ccr.corp.intel.com> References: <20160621105751.GA737@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836B74226@irsmsx105.ger.corp.intel.com> <20160621133041.GA7509@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836B7433B@irsmsx105.ger.corp.intel.com> <20160621142924.GA8670@localhost.localdomain> <6A0DE07E22DDAD4C9103DF62FEBC09090348971F@shsmsx102.ccr.corp.intel.com> <20160622023745.GA4437@localhost.localdomain> <6A0DE07E22DDAD4C9103DF62FEBC0909034897FC@shsmsx102.ccr.corp.intel.com> <20160622041431.GA6219@localhost.localdomain> <6A0DE07E22DDAD4C9103DF62FEBC090903489838@shsmsx102.ccr.corp.intel.com> <20160622061000.GA8698@localhost.localdomain> In-Reply-To: <20160622061000.GA8698@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v6 1/4] lib/librte_ether: support device reset X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 06:42:49 -0000 Hi Jerin, > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Wednesday, June 22, 2016 2:10 PM > To: Lu, Wenzhuo > Cc: Ananyev, Konstantin; Stephen Hemminger; dev@dpdk.org; Richardson, > Bruce; Chen, Jing D; Liang, Cunming; Wu, Jingjing; Zhang, Helin; > thomas.monjalon@6wind.com > Subject: Re: [dpdk-dev] [PATCH v6 1/4] lib/librte_ether: support device r= eset >=20 > On Wed, Jun 22, 2016 at 05:05:14AM +0000, Lu, Wenzhuo wrote: > > > > > > > -----Original Message----- > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > Sent: Wednesday, June 22, 2016 12:15 PM > > > To: Lu, Wenzhuo > > > Cc: Ananyev, Konstantin; Stephen Hemminger; dev@dpdk.org; > > > Richardson, Bruce; Chen, Jing D; Liang, Cunming; Wu, Jingjing; > > > Zhang, Helin; thomas.monjalon@6wind.com > > > Subject: Re: [dpdk-dev] [PATCH v6 1/4] lib/librte_ether: support > > > device reset > > > > > > On Wed, Jun 22, 2016 at 03:32:16AM +0000, Lu, Wenzhuo wrote: > > > > Lost here. I think these RTE_ETH_EVENTs are used to connect the > > > > APP call > > > back functions with the events. > > > > Actually I want the APP to register a callback function > > > > reset_event_callback for > > > the reset event. Like this, > > > > /* register reset interrupt callback */ > > > > rte_eth_dev_callback_register(portid, > > > > RTE_ETH_EVENT_INTR_RESET, reset_event_callback, > > > NULL); And when the > > > > VF driver finds PF link down/up, it should use > > > _rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_INTR_RESET) to run > > > into the callback which is provided by APP. Means reset_event_callbac= k here. > > > > > > me too. Their is existing RTE_ETH_EVENT_INTR_RESET event to notify > > > the PF reset.I guess it is not for the PF link change or it isfor > > > generic VF reset request initiated by PF for everything. > > I think this event is for device reset not only for PF but also can for= VF. I think > we can use this event when the driver want the APP to reset the device. T= he PF > link down/up caused VF reset is one of the cases. >=20 > Then please correct description for the RTE_ETH_EVENT_INTR_RESET in > lib/librte_ether/rte_ethdev.h "/**< reset interrupt event, sent to VF on = PF reset > */" >=20 > > > > > > > > file: lib/librte_ether/rte_ethdev.h > > > RTE_ETH_EVENT_INTR_RESET, > > > /**< reset interrupt event, sent to VF on PF reset */ > > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > if application need to call rte_ethdev_reset() on > > > RTE_ETH_EVENT_INTR_RESET event then please mention it commit log or > API description. > > Good suggestion. I'll try to find where's the good place to add more > explanation. >=20 > I guess then reset API can be changed to rte_ethdev_process_reset_intr() = or > similar to reflect the use case(API called by application on reset event = from PF) >=20 > The PMDs were PF does not generate the RTE_ETH_EVENT_INTR_RESET to VF > then VF's reset PMD callback shall be a 'nop' >=20 > Jerin But I don't think it's appropriate to bind the RTE_ETH_EVENTs with the APIs= . This patch set provide a reset API to reset the device. Don't mean this r= eset API only can be used when the APP hit the event RTE_ETH_EVENT_INTR_RES= ET. I can add some comments to suggest the user to call the reset API at th= at time. But I think APP can call the reset API anytime when it thinks it's= necessary. So I don't like the name *process_reset_intr*, it hints that th= is API is only for the INTR_RESET event. >=20 > > > > >