From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <wenzhuo.lu@intel.com> Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 091F1912B; Thu, 25 May 2017 02:56:40 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 May 2017 17:56:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,389,1491289200"; d="scan'208,217";a="861038393" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by FMSMGA003.fm.intel.com with ESMTP; 24 May 2017 17:56:37 -0700 Received: from fmsmsx119.amr.corp.intel.com (10.18.124.207) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 24 May 2017 17:56:37 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX119.amr.corp.intel.com (10.18.124.207) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 24 May 2017 17:56:36 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.246]) by SHSMSX104.ccr.corp.intel.com ([10.239.4.70]) with mapi id 14.03.0319.002; Thu, 25 May 2017 08:56:35 +0800 From: "Lu, Wenzhuo" <wenzhuo.lu@intel.com> To: Gregory Etelson <gregory@weka.io>, "dev@dpdk.org" <dev@dpdk.org> CC: "users@dpdk.org" <users@dpdk.org>, "Yigit, Ferruh" <ferruh.yigit@intel.com> Thread-Topic: IXBGE VF: link state detection Thread-Index: AQHS1HNAGOHmC3KQd0m6/Y9gbWtYa6IEOfgA Date: Thu, 25 May 2017 00:56:34 +0000 Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC09093B5BC8B8@shsmsx102.ccr.corp.intel.com> References: <8509342.3MbcxIPMKs@polaris> In-Reply-To: <8509342.3MbcxIPMKs@polaris> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] IXBGE VF: link state detection X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions <users.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/users>, <mailto:users-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/users/> List-Post: <mailto:users@dpdk.org> List-Help: <mailto:users-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/users>, <mailto:users-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 25 May 2017 00:56:41 -0000 Hi Gregory, After you turned the port donw/up, PF will re-init the VF's registers. So, = VF cannot work correctly. That's why you can know link down but not link up= and have to reset the process. Best regards Wenzhuo Lu From: Gregory Etelson [mailto:gregory@weka.io] Sent: Wednesday, May 24, 2017 5:50 PM To: dev@dpdk.org Cc: users@dpdk.org; Yigit, Ferruh; Lu, Wenzhuo Subject: IXBGE VF: link state detection Hello, In my tests DPDK-17.05.0 process queries link state with rte_eth_link_get()= each 50 msec during 5-20 MB/sec IOs flow. I turn Ethernet switch port down and up and check IXGBE VF PMD reaction to = link state changes. VF PMD correctly recognize link down events but may miss link up. When the fault occurs, subsequent calls to rte_eth_link_get will return lin= k_status =3D=3D 0 forever. I need to reset DPDK process to get correct link state value. My debugging shows that in case of the fault, mbx->ops.read(hw, &in_msg, 1,= 0) in ixgbe_check_mac_link_vf keeps returning non-zero value Regards, Gregory