From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0094.outbound.protection.outlook.com [157.56.111.94]) by dpdk.org (Postfix) with ESMTP id CF75B7F70 for ; Wed, 22 Jun 2016 06:14:56 +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=K8krczCa+PBLvD93kDVDaMdPNFATCUb5A5BFNslBBH0=; b=fqFpu+lISf9oRj5pbCVV5510RU3/vJY3d3U2Iso7Q7eULPsmzaMzjpVLyTFhzkJDsgs6ziny3Tu8bzN594Q5nQdxfG0UBWrcTQd1TJVZhW6GQSlYYOp/dx4buHx4b3f9IELmv2yiZWJWQkO3WBnxuZC75u4r2rl5peOxlZDhPnw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.Jacob@cavium.com; Received: from localhost.localdomain (122.171.34.83) by BLUPR0701MB1714.namprd07.prod.outlook.com (10.163.85.140) with Microsoft SMTP Server (TLS) id 15.1.517.8; Wed, 22 Jun 2016 04:14:51 +0000 Date: Wed, 22 Jun 2016 09:44:33 +0530 From: Jerin Jacob 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" Message-ID: <20160622041431.GA6219@localhost.localdomain> References: <20160621085531.GA31880@localhost.localdomain> <2601191342CEEE43887BDE71AB97725836B73FD0@irsmsx105.ger.corp.intel.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC0909034897FC@shsmsx102.ccr.corp.intel.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Originating-IP: [122.171.34.83] X-ClientProxiedBy: MA1PR01CA0015.INDPRD01.PROD.OUTLOOK.COM (10.164.117.22) To BLUPR0701MB1714.namprd07.prod.outlook.com (10.163.85.140) X-MS-Office365-Filtering-Correlation-Id: 097a0b78-fd28-4721-5860-08d39a53c3d7 X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 2:9iRznef5RO04hoTVJKM3fOjMxOpElPg4G1MqcUnoP/Dkx8ZjrJg8bBlpSPhdwiUqESoSjNkvyl00mMA21pNhTFup1uIuDB+KDbvmP82OnbxoIRdiiYXH1fKUlxgtSeVpsPw53+ewkQKbb+I8U6mZl2Tw49B8/Colt5HQi+Ul8Fo3C/bLuueZqtFBFjfjMskD; 3:pqJ5gVsTS9TxiFMXe3msgXyNwZo8KHk66luI2RYstrQHhnIU/OrBHZVbudwYb9lbOTOqnUY/PrSvGVeb/8lLV3ZHMHoxxuzYH9HBFggwMiJkHTj6+pSO5aOvTTwf6yws X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0701MB1714; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 25:T1BQ5hpgmr4cXRX5EV1ICgBZ+UByRqUui+VKqRJtnGoPvmI4o8Sj9AlslHJHbAiPyKMSFGqKuY5vh9ULSFqQo+fFD3aFhXRXpfNv8RkuSunjm+Jh68Clu/rdnP/jUlE2eTj8jUXtKiItrWYOuW7ygaYdIny5IefA+yboRvd+J2/WCQaeL0D4Mxe/H3yPpijDe3f9hXuwJ4bC5WexN0Ib8cn4CYiAJyihf7ERf6elMM4Q5anm8GY9Bzjv6RR5tB14x6n/w0FrQ2xneju39cK0qO6TETZLLqNuP4uZxLdSNPzo2QvgVnuk8Ib0T7q8l1brB95edqhFFD061AzX9tmtaPv5fn2ru0jz5PFJ35MO09PneA1N6h26jhlt+csWvKGLRi1mEs5bCAg8e1P5tME4aBbOE9IDYr/uky+7rAC5E7JFN2POHLmaVImFcGe/PRi4xE1+lSNKaA6szlkJCPxruVS/ZRNq08oJY2mOV1fWlBxOoKNiHn5YicUIkYo2naC1RteF2DMlWYv9V2ys3BXqKqJOGY7LZWMReHdQ5b0WdeKhOzr+DpEKriX1hZ4OBTFIK30DSJB+63RPyh5Nnnrl1+dYV1yi4hTNTmJhgucqOd92f4qmYP9YsEoJpUd0Q0cqjK3DvQo//JiD3V1ze4rCiGwHTmmAtiD6UXZX1JIQCiE8DcMDNNr04UX4l0T53Ep1qtcZElFPCENIz6j7XJgzmtTK6EF+yFgSQ2Xaqroeoi9nfBktXz21vjIzEN/UlGlx X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 20:eJYM4n+gez0Zl60YUDY7AAl5228sYW3DMK+VCYr9SO1wun97gQU6CudqBu+Ne9PeRZGnPb6/NQgZ9vEIbaLrEe2GTJyKdUTpdrZpSoirv/LXYWRZbzKYMqBTgNMKaJuACs9D2HeAbyaT8v9l/xyw/heL7pvkqm9iXc34W5zxcnPNsHwePKEu02JW9ARdq6sAYvyyV/L+K8r776xl32k7ngDvDSGD1WeGS6e6jp0Z8dt4TaumbyDZm0gyra1/Zp8oOW1U3V3+WRqXYlDqcbVvsaRaLzSzGpmMGuY1DsXOEEd13wJ3aHBGJA5qvKiee3kxb6xrhwwvBl+6H4idBx8wwkUpUfnrQeZQ85ConmD+hXLfMFSBXQkZWX7/NZnngjEqjl4M6Izk7D1n26TVu641HmJghbDd3xxIzPmhB4YljK9ibR5yjAZGwd02MJg/Mv2lnxHKDZ0fGvQc2Wz4hf2CG49pfVpLEMr/yVgsX2GrqlnITCalNqa3o77IRrqHaQUd1R7lOyAq3OThr38txPM43hPWnI5dQgqGJLtWgBvHNt/wSSnzMNXMQNhyKkw25tJaa361MYAMur+jUbP6h9z1xHGZuBAzaJjmKdSGgMfkww0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(21532816269658); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BLUPR0701MB1714; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0701MB1714; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 4:h7XCaPkOMglf7PCUEoR63vciQxiSwdrSVq/EDDmA5Z165HsBLdjMcrjXbk7EEsTsU9vGHB5NpHLHjeiTE5LAYWnUz/fUHJjQX75JKX+E5KztXlNXDJx8KXZn6kCGrZ31UqXXgaVWCfww27Ckzd+0H8DUAlYwfvyVP19Fh5/4bEVYJX9H+BH858CLYCTMJbcyxZVmcmXXd1GxvX8WBqJHVhHIbzd0WW3cTagx5e5k8ebrpQiSvUnqw6/oM990gjpL30hDfTWACVv2Zwz0BE4vnZwXF76j6EIVv1GQxmiqK0fLvIXM/p5cJJw1VOlqnXLUdjxefI6bxOMqahua9+xMnrp8Bc7VC+UdbNZtV0Py5uxCmo6rCH9iX4JdF2FF9/DSWAl5cbHw6jBtrXgwx+WnrdPNoCVCJq5qU865UlU1NyY= X-Forefront-PRVS: 0981815F2F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6069001)(6009001)(7916002)(13464003)(24454002)(189002)(43544003)(199003)(377454003)(2950100001)(3846002)(92566002)(68736007)(93886004)(586003)(66066001)(9686002)(76176999)(6116002)(1076002)(4001350100001)(23726003)(46406003)(50986999)(54356999)(2906002)(81166006)(101416001)(42186005)(106356001)(105586002)(97736004)(47776003)(61506002)(19580395003)(19580405001)(83506001)(77096005)(4326007)(97756001)(50466002)(7846002)(33656002)(110136002)(189998001)(8676002)(81156014)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR0701MB1714; H:localhost.localdomain; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0701MB1714; 23:A1vQdMyqfgkwrRlTaAWnsushm/Fq59mhhIP729t?= =?us-ascii?Q?qxeSoS7onMk2DYEnBXg1+6hH97zXvzKKqFKzu4HKVJE2rEvx/lFiu/lnCj8o?= =?us-ascii?Q?KYFYAfEY+poXxIPi7NiG9/ZZhErtN9+KvJR6sOXoGoR+ZyJ8DlO1qm7Iol2R?= =?us-ascii?Q?hG6MJw9IC2YnZwufnkauIxcD7OU8nXc33vcBLpLlb5CWhxTC5koFVUQUI0OH?= =?us-ascii?Q?mS+9/vPwXCdjFJoNf7CtzhBaxaxeKqK/IDv6fpTx2aQP1LLjt2HkNzf32g8R?= =?us-ascii?Q?MCmGQ+qbDltNBJ9Lm5TmOtpDGw/oUBvKIr8fZkD+qMGsdUqE9FQFKL6IGeAE?= =?us-ascii?Q?pVxZTsT3KOljGd7F5p+vjCS8/N9iE2wjehoXrK68qv/LIxbAKCY/COXVmkF0?= =?us-ascii?Q?LpWmhw8o87QkvfxRjMHqh50+NptVtvmiJQqWognuVSELmz/7UgYXAF9/cz1T?= =?us-ascii?Q?zIjXar4tBqiJR2+W3FVclQSnGhotBfsLjOJxnf5FiJkCgY12+I1zj4ahFo9i?= =?us-ascii?Q?k199mFaEJC3RThZ9Vbwo4zK/aWlAhqbqlCFa64RQP6BlzO0xlSxn3Vb+oprW?= =?us-ascii?Q?8Sp7bdghYMfqAYj5gVXvjC/bQLrmkQV0Lq/CuuAiX13PmYYyDImIastZcD1H?= =?us-ascii?Q?gs9V/GuEMMY9EZ6CFGCIN7GZiK0gDbAsenbpOQGpA+nZfe0mWGwROsq9YmSG?= =?us-ascii?Q?E0zPjOF8JCzKXGO/LLJTO0vAd3YFo8RdMXqwt0/oUNtCZEaEmLDjFIbOTbJJ?= =?us-ascii?Q?jWONqicTZGGveAqZJun+xOVJJEoGEUGBFNCIRPPpbD+K3Jy+l193+jgV4A1c?= =?us-ascii?Q?4gMuz+XSX2/PAq7IHn3JAulQYRXBeJjCu05TUnxxB+qGScumTPyEKXsPpATD?= =?us-ascii?Q?J9HXneHBxyzcUSGwo+uBRj3vcOndRTgPUNcQM19bbEmiLSDKLTIKGTarq7u3?= =?us-ascii?Q?bckQg1W54jrPOGN03tp5BSpkBfbUDO/5QjrUWMMjLktWJB39qEs5ExFboW7Z?= =?us-ascii?Q?SrE8zsFHfPK826uTMUJqA16AuRwCoPZZ6CW7eZ/TYcz3lempU8zuz6Nc5v0i?= =?us-ascii?Q?tg5GgKn2nvK1VCWpW7q+IB05Kozx/CkSU4uwPIlnd2pLfmV1oLLmFxL2vcb3?= =?us-ascii?Q?Vn8j/0pdk9Vtg/6QvfveshzifRYkjd/qI4nymfQlgDojZqWs368SX/0Yw7lq?= =?us-ascii?Q?QzUNEEpMX7X3NtqccrEDWzG/IUlWvNV6ayB1j?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0701MB1714; 6:KbN7btviGliocWReGt8/qAne4nT19UjuxqROInIg2cc9yj9LIfJc1Lu1xeCdDMpcFkgpA6RC9u6njxEVktT1wj7Trm6rOE3jOXxZtOUPFjdn4iU5OFkM/dO6E+ubJwCA7ORVF26l6jTWbVJLPBpsPsAxu6Xm0yPyaCwo61yRxM7jwfhYb9S8ld/O9EHH9+mwhE3KCfM5JycDRQ11L5dQYOi7piGWXZ5fvvwQ20q8G+Bw4+QhCgTRTJpx2lB9QqgEkhtMjmdyncdy9PV0E9IZKejoWLfH9wJEqvh4DgfdcZ0=; 5:NkRgCPup25EgJqBVNfIapxVyWo1sAJYj9VR3VnZR1ILtM/PoQ4IVUYPZPokUhuuHu/NRvx/RCxDIV47nAciNiwEfIVJgnVyS3ho943sj+h58/jkq0V6d3xgGlGnkPQxCb7t+BR4i9vN0hV5t5a6iIw==; 24:HpSMlfx4Kh/aQGxjOavwC1EpoLVj/tSKFFscHAeScXluUu9DA3EKKViuy87eoTKVY6iQnMc0ddEmGFAW+gMa0jze+G+PGC+XO45HjMRqhfM=; 7:NR+vBGR8aGBfcIi6R65WCSFjSnL4RuyF7PCPn5f8JNIeR9fBxNJg/rMwaUsDcF57iUta7sgwlx9zSZNQQuoP9CiTpznmsHQyDsn5ASqd323W+uk4UIH6RwjcieRT5zS2b8D+tIqcBlPnXAwCDDsaIFNtT4EybO9YhqxUGHL8Pef+MEegFOgA1NDhqpHvdstHsjtmHBgU65AubN15K0u6uw== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jun 2016 04:14:51.1141 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0701MB1714 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 04:14:57 -0000 On Wed, Jun 22, 2016 at 03:32:16AM +0000, Lu, Wenzhuo wrote: > Hi Jerin, > > > -----Original Message----- > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > Sent: Wednesday, June 22, 2016 10:38 AM > > 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 01:35:37AM +0000, Lu, Wenzhuo wrote: > > > Hi Jerin, > > > > > > > -----Original Message----- > > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > > Sent: Tuesday, June 21, 2016 10:29 PM > > > > 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 > > > > Subject: Re: [dpdk-dev] [PATCH v6 1/4] lib/librte_ether: support > > > > device reset > > > > > > > > On Tue, Jun 21, 2016 at 02:03:15PM +0000, Ananyev, Konstantin wrote: > > > > > > > > > > > > > > > > > > > > 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? > > > Any suggestion? I use this name because I believe what this API do is to reset > > the device. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > Hmm, the only suggestion I have here - Maintainers/developers of > > > > > non-Intel PMD will implement it for their VFs? > > > > > > > > That's fine. But, We have to know what to implement here in PMD > > perspective? > > > > That's reason being asking about the API expectation and application > > > > usage :-) > > > > > > > > > In case of course they do need to handle similar event. > > > > Which is this event and How application get notify it. > > > When the PF link is down/up, the PF will use the mailbox to send a message to > > VF. The event here means the VF receives that message from PF. So VF can know > > the physical link state changed. You see it's only for VF. PF will not receive such > > kind of message. > > > And we use the callback mechanism to let APP notified. APP should register a > > callback function. When VF driver receives the message it will call the callback > > function, then APP can know that. > > > > How about the standardizing a name for that event like > > RTE_ETH_EVENT_INTR_DOWNSTREAM_LSC or RTE_ETH_EVENT_INTR_PF_LSC > > or similar (like RTE_ETH_EVENT_INTR_RESET) and counter API in VF to handle > > the specific event whose API name similar to selected event name not > > eth_dev_reset(reset sounds like more like HW reset, In PCIe device perspective > > FLR etc) > > > > OR > > > > How about handling in more generic way where a generic alert message send by > > PF to VF like RTE_ETH_EVENT_INTR_PF_ALERT or similar. > > And have only one handle functions in VF side so that in future we can keep > > adding new functionality with out introducing new counter API in VF > > > > Jerin > 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_callback 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. 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.