From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0065.outbound.protection.outlook.com [157.56.110.65]) by dpdk.org (Postfix) with ESMTP id 51A3BADE9 for ; Tue, 21 Jun 2016 12:58:23 +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=uqH1pDtqWyyHWIXtAsSqvzXwMorCn2CifGT2P2Z5Xt8=; b=Cy2xRDJGmoBB4dmdrzXOAX65OTddGYWnqweCXWWx4WYgz5WZptpbx4bcOB5bQW+sETtwMAbW2tSsdHLbUPuX2dIOuIQVavJz9i638T3ufJG2iJp9xNkqoEPE8XU8R0LCUXiZGqsFbGiImqDpWpQuexgkbZ6g2hW3oKsPzCxqzTA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from localhost.localdomain (111.93.218.67) by CY1PR0701MB1726.namprd07.prod.outlook.com (10.163.21.140) with Microsoft SMTP Server (TLS) id 15.1.523.12; Tue, 21 Jun 2016 10:58:17 +0000 Date: Tue, 21 Jun 2016 16:27:52 +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: <20160621105751.GA737@localhost.localdomain> References: <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> <6A0DE07E22DDAD4C9103DF62FEBC090903488F5E@shsmsx102.ccr.corp.intel.com> <20160621085531.GA31880@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836B73FD0@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB97725836B73FD0@irsmsx105.ger.corp.intel.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [111.93.218.67] X-ClientProxiedBy: MAXPR01CA0009.INDPRD01.PROD.OUTLOOK.COM (10.164.147.16) To CY1PR0701MB1726.namprd07.prod.outlook.com (10.163.21.140) X-MS-Office365-Filtering-Correlation-Id: 15374958-b59d-4df8-8a36-08d399c2f52c X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1726; 2:qv5x53iIo2kWAUAWaP85Q6tKAp2//n/ux+kIyQbxSVDnKXFb0jehK6wvU9AmI1eRqMYxBfcch2SHPdSHuimWmVDDKbHu7g1ZwNvtfXmlXWOExKIKKmQe0+OvgrqWgbWk6BMwhTiLe4K24zTOsK3vp4/jBN0DB3K1zSF5PspL63ZKsSbAT9aJ1tafsKnFUgef; 3:kAKOL5vIRnQEEm9mNk6CaLHhjGfQKd9bq0VHvbWJSbDgh68+TyjmfaMwFsjSI39fx56jADWEJJF0ck4saKD+UYupjXWWsTzFk+g7h/jR4+9IDiMBMfOfZGZwoK4w4oB2 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1726; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1726; 25:8C8KtkCDn3F5S01p/jgYveK8hzQlX+VY/KManvYFjSAFl2fV+1iWyzJ4ujwK3AP90I9JwmJrPkSx5ioQ/kQO3Ue8Ttu6kX0/UjNM0+RrWxEM91trvxGh63LSVxVcRfY8d7130dC4h6bPCewET7uIEznhX0QDurmdj4Q3Oq8qW9uQYHWlxcTAZlbkdlESyenf/cs7NP5rrB0bA4q1EHM/VzLHWv9YmCnqdPjzQU30G6jrPcSiNxOmhhaWL41/qE2eLPnDkDr9SgxgCsd2SMTkuTKkzWA3fBuLq6urAx4TqMe/arFPesDmiSZB+87z0GIMjFzndrijaWyBylv+QD0AAnXyM66cFpiio5rGxUHyTIfULQ0ZgOeI4+N6VDAGyWEIEzq/sPlu26OYd68lhZgadWeEthsp0WgzcGlJCpYKM3sSI65g8ICFb/Q5qZ3ZZ2B+aFSr9nnbs2B9QUfFUVwYqsDRb6m61l9UrNNDgOxXtCzXvw/ufBjc+zo6EpiC5yAQW8wyqqMr0pupVJi/fC/KwsuVX9Gg+RFDrtoR35o3mul9NAOwdbxyQnN8Ij4TMSoSEQHtvWZtL29PJ/FjFWVyKfAFGShwI5uNMwnU4C7H7QF2U/zZumJ0+qKAGwchhkuJ8eNaZ07bIQLo7SBiYTHMfPdW4R7QBEau0PYTUvfh0+2OiX2+85WXY793Ioz+qMsQdJef6KXu1ayzrDzQTJ8GTkRMPBVLn1oAwbBIYPKYfIYkO6af7EFGeD79I6hTD/oc X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1726; 20:x+aeyVLE4Lc4503SlIojViXH8rt93/1ocX4/FzcQxggmsK9DzZDHvhFOPRh53LBuEA3w0T09iwYsmcQjylk12QwLE8IPmz45KacRksfSwXCWDKmnudjHeSCyqizx+nOITGG3hQVLr/thL6nLKNps/7+s0+RZUcabVBqkfKDS3Kc7e3EpD00/0clj8IAtQsR+7ZncRdEkFf8OBrshfvNU2+1oM/dABALA6X1D22oyDL1t9CSEIqI8x6KiAIyz7LGd5gtsy/SJHcUYCRMKj70kKU7mhvwcSU3NX8jvtyFx5krbq6eIr9CDD33vuHl/33LZN/EiNReJLHS8lS+ne3AvQIEBCJWkYIm15Nek5eFtlSKrZWJOzG32bqlArIrX089BSvd+jiD9GWLkcYERXLqM+N07QmTYA11NP6DOlgisrf6PaU6e8oHfBTWdQMr8vUzDFNKlv9P24jyfg8jZkCxH7HIgn/VOjACHOWaIJ/tCLFH4ehzRZpm8nXgbPPWLGmeof6cPH105antpI69OYFFf195O0xIz3gZ1gSY3ZGdyInNyldVOpdU14+bq3n/ug9B9BsN+/sGqRhX3ReN/hwSQR72mK3cYbtbE6iJVJBwHP4g= 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)(3002001)(10201501046); SRVR:CY1PR0701MB1726; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1726; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1726; 4:7jpp7hBNB0CekWekXPO8tIpzTUY/kxXAu3eWfRFdzoiPc7kCeQWBMXXES8JBwqjx2uiE1d+wof9n3+syw9yWhbERsbb2X5qb9nsZFAAHszEhgtCKaegbyN6L/BGW0J3zEtnkanfUbMn/NQbjgSQXbyJmIcWR9UjOMMq/viiBYLbxNI7xjIDTDoQ5WaIZdr+PGerpo0yQ+zQtG7BHbTBxmdkMbkid3SduM0lVBBsQKydJZXxB6PoiqO4VDjbpYMUqVf4bRef16dGIK+2+SzfwidWZPe3tg1UPxP8ftFk98dm2/4eAvKIbvPV2ae8P7rtkkw1pTxG9e6C4P9MWh1WW4oEiczxppJqzLFyyqz1jYXOqRXcDdXhMJEHYX+I46f6+ X-Forefront-PRVS: 098076C36C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6069001)(7916002)(13464003)(189002)(24454002)(377454003)(199003)(46406003)(83506001)(1076002)(7846002)(97756001)(42186005)(6116002)(110136002)(3846002)(4001350100001)(19580395003)(97736004)(101416001)(4326007)(189998001)(19580405001)(586003)(61506002)(66066001)(2950100001)(105586002)(23726003)(8676002)(76176999)(93886004)(81166006)(81156014)(54356999)(50986999)(50466002)(77096005)(9686002)(2906002)(33656002)(5009440100003)(106356001)(92566002)(68736007)(47776003)(7736002)(7099028); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0701MB1726; H:localhost.localdomain; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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; CY1PR0701MB1726; 23:3U7wQndBwCLyvy0EGwa85DKTeYLzf46OfnMSoBg?= =?us-ascii?Q?Jjc9i9frJMVLi4CTFW7kWGGp4shHO5wfOn0zJFfTOQjiZreIttpjVyT2V7fe?= =?us-ascii?Q?aY3KR9w83vmUV852LYWEkX3kbTyIA9W5Ao7ZrJWV7XbwK5xth/Q/pdoif/ST?= =?us-ascii?Q?X42AwrMThD/7sC7cIuV1H5Pkx7+vYi5phPsSTi1+Bk7gyTN2K9MEbKYsbGkJ?= =?us-ascii?Q?rC7bjpIyAOtEaFpGuJjlvu44UN8t0wHgTXIraY+4o/6hqBzLQEBUTPeVHR3A?= =?us-ascii?Q?MZl5XappxiG9HL/zeI1yqTMzUjQeSsp3OwdUe1OuD65RCjIUHMQX0Ktg/hA4?= =?us-ascii?Q?ONS5ZYtFJjMx2voEGsyBZzt3akIHjeSc/cMXqpdUQ7YdzdpxoHV2nHyzzwr+?= =?us-ascii?Q?0JrFL4ho2zwHuFrk8kVvY9IbK59tpgfev2+tku7KC6p5TJgO5WCIV5+CfRo1?= =?us-ascii?Q?VqL1yX0GPHyUZe2h/Vj1u0RzuCKwzXoSdtnIqYbyubV7bILhqwd8x/PwgEFC?= =?us-ascii?Q?KI+bSccv2/o0NiC2Zm0d9TuZY4SpcHafjoca8LQILAD5PFGJg4vJ2Z9SVrf/?= =?us-ascii?Q?3703AqMmIpB813E+O5uj1RixlsarzsWQfN+B8iC05DLgU4Vgd1A8QvXmRyYZ?= =?us-ascii?Q?HzJWSzt1Ln726NzBTADXRVEErhD8xKRmRheKc4aM5HgHEu2mlfx/N7IewSGl?= =?us-ascii?Q?BHZ+oXvJDvPWc8kEUvaIXyp2P/gvQI2HjaUU7Fjx8TrrignrmYP+1MpajeuT?= =?us-ascii?Q?cDsWKuxlnNx+aNOYQXWNPHwJHT2Fg6tU7FEiNaJqrCyU/8HfaQs4vHgqZkWD?= =?us-ascii?Q?amn0WyfvBG7A976rD2pgDedaxNdc8yxoYGTqsD5t0n6qk4NdtpqsY15yT28L?= =?us-ascii?Q?M8l8KQuprgE/fyBouLtoCA2lj2oPQ73nB3qxBcfj2vppAaGE4ehpN4XGzT55?= =?us-ascii?Q?FZGUSfiZMnCx4jhsJwRT6Q7HJaz02oidDfeex+w36y8xN2dYF4JDhZ+MRWpG?= =?us-ascii?Q?irLoftKC4Li0HPmTJzJfXBUnLuZNVVHeN29tPjhcrCZCeBAzfB6VRlNJst6r?= =?us-ascii?Q?8/s8CeBMF+LX8IdMG8bjK/Ya9R/TFbRDYt6+dCiWDUyfPcVfLpLLIGLWNRDf?= =?us-ascii?Q?ZlCZDw7a6uGIb7F1hsKES5g35EuCBKdLs2BucTgKBn9KmCJNxGQxvajExYAB?= =?us-ascii?Q?iibLakBUu7w21kISKaUyxf4YgBrzFPa9ksTjfpxlP7PNm5Hi2AJsoqfF2U3T?= =?us-ascii?Q?V6OpZJFrdVyDzeqsnKBU=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0701MB1726; 6:usuUEM1oVaHCfP1oCZyg8yu3oDDPs39u9MloROABNWFQa/3llsOvj1Vru2I7VFbJ/VxuwNq3GqN9b/gelFqGIZvGkTdQwbbbWsgfmEztEWYVme0vkVw4wfgqTboo3LbC6gOl3LxGsErNOG25N9/MI+pfbbGcSDjvsBbaazU/ZrlUCzZXgtR/2l5KFOyGADpFoS2JayQONnD8MxWPsoxNlezw6n/0BFuWSB2uiwr6MaXBCWKcTn6AJqOMsL0ENg9irDy/zoCi+BKQpshsNstrVOco5KjJFMn38axzm0WKo6o=; 5:bii34rtz+czVy5cDlB2ly384PqEW7BokSks07wXFL+bj1qnGkPe1pVcFzxvqwg+8ESKqHL8NcxlrOML6l2ZD2JMpXC1uIT5nohl2OBEctuFRbVqrgZcTM6G+MbQvUZwgjk8hGFTxsw1z71L2L4J6kw==; 24:aEYIoh14/bmwTmw+PI79TTV3K4LB3VRlbCJjemPbw/FFuCrMNZ0lMMJP4Xg6UA3vUdPzJnv3bqMMhIkvUj87KVu8S0ciegOeBofS6ozl8ZM=; 7:wkSTy7nOpCZsFCi3gwUyJBzOOlGKyP7HdnnXYCyr9vT++XnDJPAuIQbRyk92xsq6eWZ90Qm2pcyCJCbN5C+R+jKamZK/RaR6xTFZ6k9n6uIYHp41jyK/iUQL0X+iBO8Iglw5zs76DZ1w7lRpNqcVH1rc+5EhwkVvisfycAy7wTEOw8cl/mczXRqVyFA4mwQ/sGj+0y4OIz7ThfIatROdA3Zmkc+5sFiJERKmpOdK90gDq8g3V08rhubeBPcdfwN6 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2016 10:58:17.6657 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1726 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 10:58:23 -0000 On Tue, Jun 21, 2016 at 09:26:12AM +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? > 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. Jerin