From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0085.outbound.protection.outlook.com [207.46.100.85]) by dpdk.org (Postfix) with ESMTP id 04F28C33A for ; Tue, 21 Jun 2016 15:31:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=voBZ7lsuIPN/L9WBEunMQ+J9LLh1gI5Y+xJfB7rjKCE=; b=RMxeBD4MH1LQCMpsOhSXDODYM4JIx1m7w85NKxSzdUJ8rh2cm1sgHu7HR19nsxrQ5fCKF2ej2IpCqh+rddwTrjFhGgrMYzUqF+gF28xFwrgcmXqc7Hz45okqoQCEQ1kXFy9kJrGYM7exzCtoao4f1VOoX6UprpUfpIgliQXL1oo= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from localhost.localdomain (111.93.218.67) by CY1PR0701MB1727.namprd07.prod.outlook.com (10.163.21.141) with Microsoft SMTP Server (TLS) id 15.1.523.12; Tue, 21 Jun 2016 13:31:00 +0000 Date: Tue, 21 Jun 2016 19:00:42 +0530 From: Jerin Jacob To: "Ananyev, Konstantin" CC: "Lu, Wenzhuo" , Stephen Hemminger , "dev@dpdk.org" , "Richardson, Bruce" , "Chen, Jing D" , "Liang, Cunming" , "Wu, Jingjing" , "Zhang, Helin" , "thomas.monjalon@6wind.com" Message-ID: <20160621133041.GA7509@localhost.localdomain> References: <20160620091410.GA9323@localhost.localdomain> <20160620091714.276c186c@xeon-e3> <20160621035124.GC4903@localhost.localdomain> <6A0DE07E22DDAD4C9103DF62FEBC090903488DD1@shsmsx102.ccr.corp.intel.com> <20160621073710.GA30638@localhost.localdomain> <6A0DE07E22DDAD4C9103DF62FEBC090903488F5E@shsmsx102.ccr.corp.intel.com> <20160621085531.GA31880@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836B73FD0@irsmsx105.ger.corp.intel.com> <20160621105751.GA737@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836B74226@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB97725836B74226@irsmsx105.ger.corp.intel.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [111.93.218.67] X-ClientProxiedBy: MAXPR01CA0002.INDPRD01.PROD.OUTLOOK.COM (10.164.147.9) To CY1PR0701MB1727.namprd07.prod.outlook.com (10.163.21.141) X-MS-Office365-Filtering-Correlation-Id: aa2ada04-e14e-4c29-cddc-08d399d84ae8 X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1727; 2:oBVQmtgRNrUyrchymLftmEywrzvPPIes6TX/BTEBReD7CvWkJyKzrUKC3UquQydvjv+oVjrGuJws2GCSaW/Q2Jefi79hy8Witp4bYdbc4PkP5bV5DtmTYuKh8SRFWdk9FSqNxr+N/frc/bXe9IuqbIvtabkVclmtQF0kLMPWEcRF32up0ool9yT5QlTVk7zT; 3:jz3j36hmF9P/pgGU/M8Wrt/xb9IZufpUEBxW24dpwmp41G12RRCek5DZQX798vPYxBQsUhOjMoQN9SlAp3VvgsEkOEn6HLLph4xYluqZ6+qEwrhZzid2v8eAn5fKCMFy; 25:P1l9veKzcSFZvJoTzUtMpDCb9dnC+cfpdhhtd7hzF8MoYovBWz1bdKXY27ffxAk7Ka0Od8LiJ2gdREiduq8kicDSY6qjyKDzI9PzYyQfCHqDotG89RfF6kDnFBjFNUttmzFhiPMDl+t9OcaWBBDQOHVYd8wgu6d82QaLBnd6BuMxCyim1HfQQT6rWjt11tEz2jmMMKNyuXyzE4JHAU63w+5cW6JQ8GhSJwi5hRsz8WdLQAnRlCWwiwzpd2nLRjn4BegtAiqsOUADzIfIGGFAU8A0z97AyS5JgKfAE3M7D1Zb+vGe5epz9EpMyDf6IN1nY5+XQr5tbhVOCD62i7aHvCNbS2symi0Jy9WyiE0SSOfOk5d/8n3C2KcU+Ypwh/stNenmiGF5+jcOZCBEFBmv2FBWaE5OKgBGlsZZU/r1qdk= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1727; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1727; 20:3hjBPPzqCNBhRPlI8IRlcfvB4lmLhpff/G6tL44Rk7+tDCpX/pzZoXhSb9QvmWxkCms8KElPVloL9P8OpKudGR+qMGSPwjNuJV3tAx4Sa5oHxHzwSdlxYdKBt/14cGNdkqJ+ABaENa845PhRbo6Z2gt4w6tnq495lq/66inYNFShiJo/hPJ55d+hnwystz5jLXpWRBrLbPbB6Wm4bQ1OtEbfTC1uAeOC0zR1D9Te9Zf3ymUx9R8vSb0NFnIdTCkO/NIyD5BtTZsxtm+I4/cGxCGD06zJnhTwDzb6kQCwpM8ZUbOs7nSKcbE2PKhn/FiqMB1cpNvjv6cIwQ5IczOg3akgGF5gd9k2JWGljdPJaHDz+ASiRi6j2fKXp5uiYnZnHvy01xrw6LDE9jPodtOxp59WDDe3aznCphiu6LsJN1IdLWTxZHZuE3jtDFsSFTwzEgBWSNrAWq/fQgZa9t0/2kRmESQ+aHYIC+uUx7QMTRuo/onRkJDMt2d7ukDoVbN0bbc+FyQzV3rv8pX0t/K0mmBnvsXY35M5BNXw8skow4WYU5H0oOlN0LQG6WR+AHgDDI4cKj/+Hv18FBCNHpxkVCDG5UK/DS9cDzslcbKd9Bw= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:CY1PR0701MB1727; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1727; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1727; 4:HeWovO0IfZXiLbwb06ZYRkoYp4p1DshFNiV2n7eJEcQ3OzSjpzLHS6MH44BIuL5mWV01TOVBK+Sq2eAg55aqcGQNARatR4HCxES1SyV6AWPVwiH+GXXJIE0D6dJqjNKwv0J0Y0jmXFV33LyVBQFHcilreoFA4DjS+1vpwfft1Juf00mRo+/Mxy9Oub0/f6unl3lLphwUIu9D3tIxqbpEItnpQMCCAOUaIY0UXwT9QQI4CMZniHMOvF1Yp8YA02I/70BXqyH2yutia7ItL0FAdIq6NPoD3fzC5zrVsSZ2Hlgqte0AgsFeWuu0fwRnXLKS29wsBmna4SdpPZlbJ980nCqd0XiAZgxbKWWSTqLIZTnetuNhrXXkGmS3x73mVM7e X-Forefront-PRVS: 098076C36C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6069001)(6009001)(7916002)(43544003)(199003)(377454003)(13464003)(189002)(24454002)(97736004)(106356001)(105586002)(19580405001)(47776003)(97756001)(61506002)(19580395003)(81166006)(2906002)(50986999)(101416001)(42186005)(33656002)(7736002)(77096005)(8676002)(81156014)(5009440100003)(110136002)(189998001)(4326007)(83506001)(4001350100001)(586003)(66066001)(68736007)(9686002)(76176999)(7846002)(2950100001)(6116002)(93886004)(3846002)(92566002)(1076002)(23726003)(50466002)(46406003)(54356999)(7099028); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0701MB1727; H:localhost.localdomain; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0701MB1727; 23:d+BWhFVVpbMMsVuCbwA330b5EGX3Os3JTo74OOf?= =?us-ascii?Q?C0TPGOgxIBr3gWbykEUUuGMTnFgZkQ30YZb3O1XKeg6psttL7Xuzct053oOC?= =?us-ascii?Q?O2zXojxXtjel3r2IYA1ryNpn0sFUmc4nwWVQXrbLqxyQpLT2AW8ITMDyaOom?= =?us-ascii?Q?hqigD+jGPJ1oTKeKyBc504ycq6n0PHKfH+zBstiZysxtX9hmfnpjvkDrHvhE?= =?us-ascii?Q?7fViDTSLazpvIW8eT03OumPrwT/DTaFDrxcu/JCbghrS/Lm75D7+vAjaWBcW?= =?us-ascii?Q?Fl1xlcNiZlijTbEj4bNb47epcXy+u0Z1azQqqr/Jbw0defTzYDv4RQlPKjiT?= =?us-ascii?Q?bslGa6qLQtujcAQivGd/Q5HJ0bqUSdyIywllRTyhf+42+gFaciLKZ9rg6JAL?= =?us-ascii?Q?23dYnzwERKVJe7ZwGyEB4556Pg0p/q02j16jjxwEJvT1upz8mhlgwZwHCUZB?= =?us-ascii?Q?sVyAUf+CEcMD0qull3HwSXrty6zmb4SIGZG/5C2kFrOb1s2Fxg/hhRCtaAXk?= =?us-ascii?Q?KSdrN1fTCnTWUzHHMkulZWTw4tTVd9NUpPWZx4mhBlLXQ5kLla58JogXierb?= =?us-ascii?Q?4HZ/qnPOjUmCrOH6KTI9p013LokRuOngT+Pfs0O+vKprJdqx5MMMoK4qnOJn?= =?us-ascii?Q?grfwbAUeVbJB3EflWYvrRw75nNrvf5oGMp3zNBh5Deag8+tSU63Q5tSZ989d?= =?us-ascii?Q?mfEUxy9nmMLJ+T+kwr6UQKCwgfT3jOSou6i5WWhkcB4l8yjmO8CmC2D59tK4?= =?us-ascii?Q?nHDOYcEO8sYCCDgUnDq9eN0tgICF2S8V/ZAdi69t68nWkPsWtsOqE1Rme0mV?= =?us-ascii?Q?ftPCkFsFrFNmEcFR+krKmdBNckNlOyY1hjkz4pbTTOQadykOqKMIGPxPa7b/?= =?us-ascii?Q?fLyRiR9zZ7IyD8suOpztmf+UPkICTo/VBWTyzBBdAeg7pZZMn/wBHcBcnSUm?= =?us-ascii?Q?Hbgs2sdiGz6bDK3hhjEXZZwGV8eafjRXx9dMBbBXNPDSPtqY7+xHFT42W09O?= =?us-ascii?Q?nynhtffdE73lgbxPN4fWuPSWhCMNRi/FM1k+ZSHpZEBQbEf8UvowTiNKeVfj?= =?us-ascii?Q?qWF2o4RPhP6MjlpIq9dgG5O57VzZosalgZswh4F62tUNzQWVtnW/kJ7h9EaB?= =?us-ascii?Q?dtzW6HPCLNWe81MX60GwkFsqgWD5Aqascmp5W/GTN2QKGDJIc+DBpt6lIs7x?= =?us-ascii?Q?xS2EZ3EYXNfAZPc0wv/LfQvTZUp81lIimcARvPQRDW5PQKAEXdiDbbspfx5N?= =?us-ascii?Q?KaJTOuVjkF9XmCrARFZUr7jKWHtATQpkuRpYmm3+t?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1727; 6:xtVwrCeSjSECkJicygEwGvMauxcYk7H2GAJaK/ugM1xw9XUlxH7gw4769GXr/IH8bESpRO8IVRC1ACpOudMZP3MR9kcYp0iZ+ZZE0B3Cieom7uqal4Nvx55w6LGZoRTaS6qHxHnAWMjQgMfENzkNAEaxQG0KC/tSd94JdCK7CIFMhz4BmFufZ2ME796HGKpxQcwvTjEAfYc2A/GMEjQlxG8M9x9ilRuX6N+BYTnfSgqvWxtcLueBs0xWzovB/PcXcdtQ2KqV8UcioUHXwXIjyOIStF3uZuckze4lbfnLv94=; 5:DvXFSR9Vb2cf6fp1w/28nJEISxAYxRN/j6oYyYaSvcd5anT6URtR07u2F+UpvQ472ISWrzdRWjCN4GBG/iGq9dPzU6ar5RIa+aIIrq9tNE4gx1BAoKkeSs9abRuQV4kkzluz9WSc+sHnuJyNx/DFAg==; 24:MqlPRsNcrK8d7YjWkobOhS72KX5UoRjh+oLlYxd5XujnWt5VMkMgPbTnmTEFPUQXEhzF6OtrhYCEUs0DLw1M4bRIeMzFRIsIQ3qtEQtQYpk=; 7:YJL1uFssqPVaQLTQ++7LgdnJqu6FA9MVWC1apFKUYOXgfUr85MDa4uhiRkxhvAZ+UfnTTNetPsDZ+rEhpX8+ULoimcfkQ8qjfCVmqdTAcFlCT+0z/ofuVj4OB735bNMTBAPmZ2pxvCymm37Wqrt/NZE+mMUF8USv51DGrr+504D5owkn5SDpC8Dykbr08Pa5XLyqKmqKhBgcM3uZKAG+9eFXWNBB/H2D5j3vmWvxRONijAm+VchtHQgvwIh++RQo SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2016 13:31:00.5278 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1727 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 13:31:06 -0000 On Tue, Jun 21, 2016 at 01:10:40PM +0000, Ananyev, Konstantin wrote: > > > > > > Hi Konstantin, > > > > > Hi Jerin, > > > > > > > -----Original Message----- > > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > > Sent: Tuesday, June 21, 2016 9:56 AM > > > > 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 reset > > > > > > > > On Tue, Jun 21, 2016 at 08:24:36AM +0000, Lu, Wenzhuo wrote: > > > > > Hi Jerin, > > > > > > > > Hi Wenzhuo, > > > > > > > > > > > > > > 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, stop > > > > > > device -> stop queue -> re-setup queue -> start queue -> start device ? > > > > > > > > > > > > What was the expected API call sequence when you were introduced this API? > > > > > > > > > > > > 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_setup -> rte_eth_tx_queue_setup - > > > > > > > rte_eth_dev_start. > > > > > Actually our purpose is to use this reset API instead of the API call sequence. You can see the reset API is not necessary. The > > benefit > > > > is to save the code for APP. > > > > > > > > Then I am bit confused with original commit log description. > > > > | > > > > |It means APP should stop the rx/tx and the device, then reset the > > > > |device, then recover the device and rx/tx. > > > > | > > > > I was under impression that it a low level reset API for this device? Is > > > > n't it? > > > > > > > > The other issue is generalized outlook of the API, Certain PMD will not > > > > have PF link down/up event? Link down/up and only connected to VF and PF > > > > only for configuration. > > > > > > > > How about fixing it more transparently in PMD driver itself as > > > > PMD driver knows the PF link up/down event, Is it possible to > > > > recover the VF on that event if its only matter of resetting it? > > > > > > I think we already went through that discussion on the list. > > > Unfortunately with current dpdk design it is hardly possible. > > > To achieve that we need to introduce some sort of synchronisation > > > between IO and control APIs (locking or so). > > > Actually I am not sure why having a special reset function will be a problem. > > > > | > > |It means APP should stop the rx/tx and the device, then reset the > > |device, then recover the device and rx/tx. > > | > > Just to understand, If application still need to do the stop then what > > value addtion reset API brings on the table? > > If application calls dev_reset() it doesn't need to call dev_stop() before it. > dev_reset() will take care of it. > But it needs to make sure that no other thread will try to modify that device state > (either dev_stop/start, or eth_rx_busrst/eth_tx_burst) while the reset op is in place. OK. This description looks different than commit log and API doxygen comment. Please fix it. How about a different name for this API. Device reset is too generic? > > > > > > > > Yes, it would exist only for VFs, for PF it could be left unimplemented. > > > Though it definitely seems more convenient from user point of view, > > > they would know: to handle VF reset event, they just need to call that > > > particular function, not to re-implement their own. > > What if driver returns "not implemented" then application will have do > > generic rte_eth_dev_stop/rte_eth_dev_start. > >That way in application perspective we are NOT solving any problem. > > True, but as I said for PF application would just never receive such event. What is this event ? Is it VF Link up/down event? No I was referring to VF itself, Other VF PMD drivers in drivers/net where this callback is not implemented. Jerin > I suppose it is possible to implement one for PF too, I just don't see > much point - as probably no-one will ever use it. > > Konstantin