From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 41616914B for ; Thu, 25 May 2017 05:45:24 +0200 (CEST) Received: by mail-wm0-f43.google.com with SMTP id d127so84418678wmf.0 for ; Wed, 24 May 2017 20:45:24 -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:in-reply-to :references:mime-version:content-transfer-encoding; bh=VoX6xg6v8Hh+bWx7aL+h1t45cA4yguXkxNL8tc2a5jk=; b=A6fDAFp3tNmhFCBRBG6Q6vaiNIJKRBBLEsUngO7u154USr/8rMqSm6kU/m/Nf8xpcS SOT/nwY7LvLirdlgSnAZavkaIyahlgfmd5CRwgWnt/ChY6pQ+lzOvNljz0T9LDA33Kep mnhkTL54843BRc2LJY6zpEUAu6Fm7CTnYQd6M= 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 :in-reply-to:references:mime-version:content-transfer-encoding; bh=VoX6xg6v8Hh+bWx7aL+h1t45cA4yguXkxNL8tc2a5jk=; b=qj/Da8U5K0s7/2ensgg7GS2X8VvyKmDxyCRsxPsmvmkwLmhn3YIsh6ye0lsoaBj9F0 G5rw9bAMxUJHr1YhmLNzpkQSf9ILC9mxS1D+0Ij6WctwErMh3m0OIwmd6Qm8RH+iTPFr GxRjQvfup4HG56fsgoP6oE+jlidFLgupNtA3nxIXISo467krhGf4u+kcM3uOILnQcycf V6i5lz75j+GBskKYvbphu//rK7YFmiaoCIKf1sFBRL+gnfUkEcnW+7XqyfSNI3xTEg4e Omtu4ibVWX9lPf1j2ZaIco4xyldic2Sqlumy71H8lZt1rp9sXvCeHZO8e/NcMcJryh15 pWFQ== X-Gm-Message-State: AODbwcC1IbnTUXg4ZsKSwJFweK4JghlOJ3BgKW65RXwhw6TQvzoZN9Up Y7rFH82mqrvdWM33 X-Received: by 10.28.136.85 with SMTP id k82mr7789422wmd.55.1495683924606; Wed, 24 May 2017 20:45:24 -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 4sm10117112wrv.33.2017.05.24.20.45.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 20:45:23 -0700 (PDT) From: Gregory Etelson To: "Lu, Wenzhuo" Cc: "dev@dpdk.org" , "users@dpdk.org" , "Yigit, Ferruh" Date: Thu, 25 May 2017 06:45:22 +0300 Message-ID: <1555038.6RsqslMA5V@polaris> Organization: Weka.IO In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093B5BC8B8@shsmsx102.ccr.corp.intel.com> References: <8509342.3MbcxIPMKs@polaris> <6A0DE07E22DDAD4C9103DF62FEBC09093B5BC8B8@shsmsx102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 May 2017 03:45:25 -0000 Hello, In this case I would expect ixgbe VF bound to kernel driver also fail on link up detection In my tests, VFs bound to kernel drivers operate correctly. Regards, Gregory On Thursday, 25 May 2017 03:56:34 IDT Lu, Wenzhuo wrote: Hi Gregory, After you turned the port donw/up, PF will re-init the VF=E2=80=99s registe= rs. So, VF cannot work correctly. That=E2=80=99s why you can know link down= but not link up and have to reset the process. =20 =20 Best regards Wenzhuo Lu =20 *From:* Gregory Etelson [mailto:gregory@weka.io]=20 *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 =20 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.=20 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=20