From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0071.outbound.protection.outlook.com [104.47.42.71]) by dpdk.org (Postfix) with ESMTP id 446C17D3F for ; Wed, 23 Aug 2017 00:07:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cienacorp.onmicrosoft.com; s=selector1-ciena-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=M8vqOcEXo3gRE8LgNJXXTX3a+RvXJCk0oNd7yN6VA6Q=; b=cc/gD1uRWn33S6VaOo6uyI3lWe2MbDpmRLF71X6FwAJOvQMRni3lazFsO+Cs9fwa7nJZ6uMZqj98iK2cOMthF6E6j7pm+sosqofde+41LGohUALLz6uxw0uJBJMgw+NdFK7ng7kiIrY7195D6207rdZapqPjepde/wsf+gsK8rQ= Received: from BN6PR04MB0594.namprd04.prod.outlook.com (10.173.201.147) by BN6PR04MB0642.namprd04.prod.outlook.com (10.172.197.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.18; Tue, 22 Aug 2017 22:07:56 +0000 Received: from BN6PR04MB0594.namprd04.prod.outlook.com ([10.173.201.147]) by BN6PR04MB0594.namprd04.prod.outlook.com ([10.173.201.147]) with mapi id 15.01.1362.019; Tue, 22 Aug 2017 22:07:56 +0000 From: "Yeddula, Avinash" To: "dev@dpdk.org" CC: "Gajarampalli, Prasanth" Thread-Topic: link state change not consistent (Flaps/stays DOWN/UP for ever) Thread-Index: AdMbkpbwS8gtsEz6SPOAdUM5UuRqrA== Date: Tue, 22 Aug 2017 22:07:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ayeddula@ciena.com; x-originating-ip: [63.80.42.139] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR04MB0642; 6:lEg8g76qqn3hYK+2Ho8hS+23rVUs8YnfqovdQ/bQUoO/BA5Dq85RmZsnwvqY9pur9eIlDUdFC9wFz457lhXTJGAS5E8ZjhIaemLEhk6tRrs2Zlw/7EGtacqG5/3uMxvtRdU6JQjqArjD6TI+0oMnyfg+CxP3ijdra10HuRkMLXFrJxx9qlA8n3wWW82uoMK2LLWGHKLyqI1hQzxTKldmjbIeSWM2c+HUdx3SWlZp99yIhtvImGrYxjWl1LFDCpOVx7PGQM2mdKupEjRIqv+5cYNm1HMnuLdDclqpLQRzUadZGB3SljztpKbO86WuZ3H3p+ufNXRl1y2YjvNwgKlQ5A==; 5:3ObWyMzMN5Ti+u4dQyp4doeIvK17ywm++FjBx0RhaqOeymfuoyBAV9GYlRPjq0P4rX1rX1wycneTysO2kmbiBSAf9nThF6eZrW/kLwa/dvGXGnmQVdjTU5KQgfg2ZzMkRb94oGh63WKscWrlMMSx2Q==; 24:2E55fd1vWjvMCpKKQ8Bdg1hWI51gOBrPlQVAfNYJuSm4wnpBHbZepD7OgCfBUyc0PNvqbF/660jJt0TPTGkuP/q9rtElMuxQCJ2dCZ9/6yU=; 7:F2KVz8N6IfbYWj6vYLqfxXCUK84tH+VCja6EEoP7LlvYoqnfRuhqfl2+5QzmmNOGjrTsiH3z+PTDdeO9VuYhpG9706hq9NIcY/F+tNH9hRWI/SyW0tQH1CM7NNsVRa/I+OUpS7Z6tjXiDOaBQnC77OlpwWDpvoIaTTuqFTouA9WxYzkwhAnX97Me5jtoE+5hMi2o9f2CbgzTLD5cL+BQaJlOWeuvsfH8srsGsjwV1rM= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(6009001)(53754006)(43544003)(189002)(199003)(99286003)(68736007)(9686003)(2900100001)(5630700001)(6306002)(55016002)(189998001)(107886003)(54896002)(53936002)(66066001)(54356999)(7736002)(6436002)(6116002)(2906002)(3280700002)(50986999)(3660700001)(74316002)(110136004)(4326008)(14454004)(25786009)(97736004)(3846002)(790700001)(102836003)(1730700003)(77096006)(478600001)(9326002)(5660300001)(101416001)(106356001)(8676002)(81156014)(81166006)(2501003)(33656002)(86362001)(7696004)(105586002)(6916009)(6506006)(8936002)(5640700003)(2351001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR04MB0642; H:BN6PR04MB0594.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 69c56233-ab0c-47fe-f034-08d4e9aa3e02 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603174)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR04MB0642; x-ms-traffictypediagnostic: BN6PR04MB0642: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR04MB0642; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR04MB0642; x-forefront-prvs: 04073E895A received-spf: None (protection.outlook.com: ciena.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2017 22:07:55.8612 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR04MB0642 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] link state change not consistent (Flaps/stays DOWN/UP for ever) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 22:07:59 -0000 Hi All, With DPDK Stable 17.05 branch, we are seeing an issue with the link state o= f 10G ports on Broadwell. Link status of one of the ports keeps flapping at regular intervals, typica= lly starts after few seconds after the link appeared to settle down. Other behaviors include not honoring a link state change set by the app. So= far this is observed with ixgbe only, but have not yet explored if the iss= ue is existing across drivers. Also this issue was not seen with 16.11.2. Is this a known issue? If yes, a= re there any patches that can fix it? Few patches (between 17.05 and 17.08) that were applied and not found any d= ifference in behavior are below. net/ixgbe: improve link state check on VF In current implementation, when checking VF link state, PF state is checked too, although the function has a parameter to tell if PF state checking is needed. But in some scenario, user may not care about the PF state. This patch enables the unused parameter to only check the VF link state. net/ixgbe: fix LSC interrupt If LSC flag is changed to off at last device start, the enable flag is not cleared in HW. This patch fixes it. net/e1000: fix LSC interrupt If LSC flag is changed to off at last device start, the enable flag is not cleared in HW. This patch fixes it. ethdev: add deferred intermediate device state This device state means that the device is managed externally, by whichever party has set this state (PMD or application). Note: this new device state is only an information. The related device structure and operators are still valid and can be used normally. It is however made private by device management helpers within ethdev, making the device invisible to applications. ethdev: count devices consistently Make the rte_eth_dev_count() return the number of available devices even after some are detached by the hotplug API or put in a deferred state. net/ixgbe: fix Rx/Tx queue interrupt for x550 devices x550 devices don't map interrupt vector before enabling Rx/Tx queue interrupt. Because of this interrupt mode is not working for x550 devices. igb_uio: issue FLR during open and release of device file Set UIO info device file operations open and release. Call pci reset function inside open and release to clear device state at start and end. Copied this behaviour from vfio_pci kernel module code. With this patch, it is not mandatory to issue FLR by PMD's during init and close. Bus master enable and disable are added in open and release respectively to take care of device DMA. ethdev: fix device state on detach The device state should be handled by the ethdev layer when possible. Applications should not have to do it. Not setting the state to UNUSED will make the port_id of the device valid for all ethdev API functions, usually resulting in segfault.