From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gregory@weka.io>
Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49])
 by dpdk.org (Postfix) with ESMTP id E22B27CB3
 for <dev@dpdk.org>; Wed, 24 May 2017 11:50:21 +0200 (CEST)
Received: by mail-wm0-f49.google.com with SMTP id 7so57446772wmo.1
 for <dev@dpdk.org>; Wed, 24 May 2017 02:50:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=weka.io; s=google;
 h=from:to:cc:subject:date:message-id:organization:mime-version
 :content-transfer-encoding;
 bh=gpx29Ql5JXSDLfHh/BB4/ZpmBnjtpx4+uLtq+hb1vdk=;
 b=HlepmwfAszs6UqBAKFrJvM//Stid1cZavOPq3lHfdmcz83kh9/YUl04LNtrLXiDBUL
 QI8BmJtz96Oz5DigkuqOikoin5B8Kcg3cLsD0fTsq2POwxkuxlY+49s/SovBh9I55l2Z
 KY/P2YUlzoj2Bw64n1EqP5UGg+SP8LN519tS8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:organization
 :mime-version:content-transfer-encoding;
 bh=gpx29Ql5JXSDLfHh/BB4/ZpmBnjtpx4+uLtq+hb1vdk=;
 b=iARtH8sgd724ENG7jaxS+bVVpbAfxi3itxzzoV1uW9M0WUVPeZCqQeD1ALDs7DtVfR
 TqgPjCZ5ZAAOgJ3t1rYzq6XK+oJ/KPyrG5M2JEKvR07z8mu9cItgUIa6sJV9zIMbSyzr
 BOiqNsbnH0yCmo2nl6vwzzgXCGxctGxChYjnPt8kuOX0zDW8fn/V2yjnsapN0uIgANNZ
 0Q1u8PVGuzcxXniUkCb54ETJQuEDcsQe0YjchHDuZtHb53l3HV5geYdm4f3mZZEeVSL+
 SLC00YCot8+Ib1QUpo6/giSaiUGaQK9WYOM/PElKfQCZ7hUiw+3NMdBVyOqfj4YikYkg
 E7UA==
X-Gm-Message-State: AODbwcAJI3+lPUa9swgHElKXhWu9YNtHzTpEHXaxuoRQRm4+1q/stCu5
 D0SXnZ7NG4dc3l1D
X-Received: by 10.28.175.136 with SMTP id y130mr5780374wme.112.1495619421186; 
 Wed, 24 May 2017 02:50:21 -0700 (PDT)
Received: from polaris.localnet (bzq-82-81-85-138.red.bezeqint.net.
 [82.81.85.138])
 by smtp.gmail.com with ESMTPSA id 53sm4870583wrt.36.2017.05.24.02.50.20
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 24 May 2017 02:50:20 -0700 (PDT)
From: Gregory Etelson <gregory@weka.io>
To: dev@dpdk.org
Cc: users@dpdk.org, Ferruh Yigit <ferruh.yigit@intel.com>, wenzhuo.lu@intel.com
Date: Wed, 24 May 2017 12:50:19 +0300
Message-ID: <8509342.3MbcxIPMKs@polaris>
Organization: Weka.IO
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: [dpdk-dev] IXBGE VF: link state detection
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 24 May 2017 09:50:22 -0000

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 link_status == 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