From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 6FE5C6004 for ; Tue, 21 Jun 2016 10:24:40 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP; 21 Jun 2016 01:24:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,502,1459839600"; d="scan'208";a="722718670" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by FMSMGA003.fm.intel.com with ESMTP; 21 Jun 2016 01:24:40 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 21 Jun 2016 01:24:39 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.147]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.181]) with mapi id 14.03.0248.002; Tue, 21 Jun 2016 16:24:37 +0800 From: "Lu, Wenzhuo" To: Jerin Jacob CC: Stephen Hemminger , "dev@dpdk.org" , "Ananyev, Konstantin" , "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//+UC4CAAIsykA== Date: Tue, 21 Jun 2016 08:24:36 +0000 Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC090903488F5E@shsmsx102.ccr.corp.intel.com> References: <1465191653-28408-1-git-send-email-wenzhuo.lu@intel.com> <1466403870-6840-1-git-send-email-wenzhuo.lu@intel.com> <1466403870-6840-2-git-send-email-wenzhuo.lu@intel.com> <20160620091410.GA9323@localhost.localdomain> <20160620091714.276c186c@xeon-e3> <20160621035124.GC4903@localhost.localdomain> <6A0DE07E22DDAD4C9103DF62FEBC090903488DD1@shsmsx102.ccr.corp.intel.com> <20160621073710.GA30638@localhost.localdomain> In-Reply-To: <20160621073710.GA30638@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: Tue, 21 Jun 2016 08:24:41 -0000 Hi Jerin, > -----Original Message----- > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > Sent: Tuesday, June 21, 2016 3:37 PM > To: Lu, Wenzhuo > Cc: Stephen Hemminger; dev@dpdk.org; Ananyev, Konstantin; 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 Tue, Jun 21, 2016 at 06:14:29AM +0000, Lu, Wenzhuo wrote: > > Hi Jerin, Stephen, > > > > > > > -----Original Message----- > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > Sent: Tuesday, June 21, 2016 11:51 AM > > > To: Stephen Hemminger > > > Cc: Lu, Wenzhuo; dev@dpdk.org; Ananyev, Konstantin; 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 Mon, Jun 20, 2016 at 09:17:14AM -0700, Stephen Hemminger wrote: > > > > On Mon, 20 Jun 2016 14:44:11 +0530 Jerin Jacob > > > > wrote: > > > > > > > > > On Mon, Jun 20, 2016 at 02:24:27PM +0800, Wenzhuo Lu wrote: > > > > > > Add an API to reset the device. > > > > > > It's for VF device in this scenario, kernel PF + DPDK VF. > > > > > > When the PF port down->up, APP should call this API to reset > > > > > > VF port. Most likely, APP should call it in its management > > > > > > thread and guarantee the thread safe. It means APP should stop > > > > > > the rx/tx and the device, then reset the device, then recover > > > > > > the device and rx/tx. > > > > > > > > > > Following is _a_ use-case for Device reset. But may be not be > > > > > _the_ use case. IMO, We need to first say expected behavior of > > > > > this API and add a use-case later. > > > > > > > > > > Other use-case would be, PCIe VF with functional level reset for > > > > > SRIOV migration. > > > > > Are we on same page? > > > > > > > > > > > > In my experience with Linux devices, this is normally handled by > > > > the device driver in the start routine. Since any use case which > > > > needs this is going to do a stop/reset/start sequence, why not > > > > just have the VF device driver do this in the start routine?. > > > > > > > > Adding yet another API and state transistion if not necessary > > > > increases the complexity and required test cases for all devices. > > > > > > I agree with Stephen here.I think if application needs to call start > > > after the device reset then we could add this logic in start itself > > > rather exposing a yet another API > > Do you mean changing the device_start to include all these actions, sto= p > device -> stop queue -> re-setup queue -> start queue -> start device ? >=20 > What was the expected API call sequence when you were introduced this API= ? >=20 > Point was to have implicit device reset in the API call sequence(Wherever= make > sense for specific PMD) I think the API call sequence depends on the implementation of the APP. Let= 's say if there's not this reset API, APP can use this API call sequence to= handle the PF link down/up event, rte_eth_dev_close -> rte_eth_rx_queue_se= tup -> rte_eth_tx_queue_setup -> rte_eth_dev_start.=20 Actually our purpose is to use this reset API instead of the API call seque= nce. You can see the reset API is not necessary. The benefit is to save the= code for APP. >=20 > Jerin >=20 > > > > > > > > >