From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gregory@weka.io>
Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45])
 by dpdk.org (Postfix) with ESMTP id AD6F45A3E
 for <users@dpdk.org>; Wed, 24 May 2017 11:50:21 +0200 (CEST)
Received: by mail-wm0-f45.google.com with SMTP id b84so58078169wmh.0
 for <users@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=RA1c3KKzytUoLzfP0pnzGj76wlUzmLZBbMkph2H33snjSkypXc/8beshjVCcMOBuha
 YQFvTuU8/Dm4YEsgyCmZiBfT5c/BtPrrxqck/s3sPFJaEIPUWXRikcVKlG2nfnwgFv8Y
 cLWV24+Tn8BPNAmeQAr7fUK7v5SygdR55XFPSCflfsvgSBffzA2NyeKLcjS+NGDzCSTT
 oV76aWLkALCJd4+VosByP+kGoCQR/SMsirTNV4cy/GHEv4diji/sv82r6UR8h2Puiluc
 e3ei99WgyZ/SNgp2v5G9frqyPuh5E72q22DE0J5dz0jWopRBe2QWs33ccvq3VRtxmo5O
 jr7w==
X-Gm-Message-State: AODbwcC2MaMx8zhxKKQ1421dvI1EUktd5E9tCKeIf4cQRNe8XipRqQG3
 AgKUk6fJcMod0RsD
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-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: Wed, 24 May 2017 09:50:21 -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