From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 6A0958D93 for ; Thu, 23 Jun 2016 02:39:34 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 22 Jun 2016 17:39:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,509,1459839600"; d="scan'208";a="1007801595" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga002.fm.intel.com with ESMTP; 22 Jun 2016 17:39:33 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 22 Jun 2016 17:39:33 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.147]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.230]) with mapi id 14.03.0248.002; Thu, 23 Jun 2016 08:39:31 +0800 From: "Lu, Wenzhuo" To: Thomas Monjalon , Jerin Jacob CC: "dev@dpdk.org" , "Ananyev, Konstantin" , Stephen Hemminger , "Richardson, Bruce" , "Chen, Jing D" , "Liang, Cunming" , "Wu, Jingjing" , "Zhang, Helin" Thread-Topic: [dpdk-dev] [PATCH v6 1/4] lib/librte_ether: support device reset Thread-Index: AQHRyrx6NqZsK6LoQ0Kr0EDRoXtySZ/xjKGAgAB2MwCAAMH0gIAAqwkw//+UC4CAAIsykP//irIAgAAIkQCAABmdAIAAJRoAgAAFmQCAAAkYgIAAB1CAgAE5dBD//5INgAASMuVg//+JcoD//22SwIAAsrIA//9zMjCAAKtmAIAABPIA//942+AAEwcbgP/+eb4Q Date: Thu, 23 Jun 2016 00:39:30 +0000 Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC090903489D75@shsmsx102.ccr.corp.intel.com> References: <20160621133041.GA7509@localhost.localdomain> <6749084.arHGZf8DkE@xps13> <6A0DE07E22DDAD4C9103DF62FEBC09090348995A@shsmsx102.ccr.corp.intel.com> <6984459.KfxJSr4bsX@xps13> In-Reply-To: <6984459.KfxJSr4bsX@xps13> 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: Thu, 23 Jun 2016 00:39:35 -0000 Hi Thomas, > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Wednesday, June 22, 2016 5:18 PM > To: Lu, Wenzhuo; Jerin Jacob > Cc: dev@dpdk.org; Ananyev, Konstantin; Stephen Hemminger; Richardson, > Bruce; Chen, Jing D; Liang, Cunming; Wu, Jingjing; Zhang, Helin > Subject: Re: [dpdk-dev] [PATCH v6 1/4] lib/librte_ether: support device r= eset >=20 > 2016-06-22 08:25, Lu, Wenzhuo: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > 2016-06-22 13:29, Jerin Jacob: > > > > Thomas, > > > > As a librte_ether maintainer any comments on this? > > > > > > +1 for adding details and make sure naming is good. > > > I don't really need to comment here because I have already done this > > > comment > > > earlier: > > > http://dpdk.org/ml/archives/dev/2016-June/041845.html > > > Thank you for insisting. > > I've add some details in this patch set. If it's not enough, please let= me know. > > And I think this discussion is about what the API name should be like. = Actually I > think all the existing name is describing what is done by the API not whe= n and > where it should be used, like dev_start/stop. >=20 > You're right, I overlooked it: >=20 > + * The API will stop the port, clear the rx/tx queues, re-setup the > + rx/tx > + * queues, restart the port. >=20 > Jerin, which detail do you think is needed? >=20 > Wenzhuo, why this function is needed? As you said below and discussed before, it's a wrapper of the existing func= tions. The benefit is helping the users avoid the complex implementation wh= en they want to stop and re-start the device. > All these actions are already possible independently. > When looking at ixgbe implementation, I see: > ixgbevf_dev_stats_reset() which is not documented in the API > rte_delay_ms(1000); > do {} while > It looks to be some hacks. > If you really need some workarounds to handle some tricky situations, may= be > that the API is not detailed enough. Yes, you're right. Still something left. I'll add more detail. >=20 > > But anyway I'm open for changing the name. Is the name process_reset_in= tr > you prefer? Thanks. >=20 > Not sure. > If you really intend to add a generic reset, maybe rte_eth_dev_reset() is= a good > name. We just need more justification. > After reading the doc, the user can understand it is just a wrapper of ex= isting > functions. But it appears in the code that it does more and can help in s= ome > situations. I'll add more info. Thanks.