From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id 3891999BC for ; Fri, 26 May 2017 06:25:59 +0200 (CEST) Received: by mail-wm0-f44.google.com with SMTP id e127so6163951wmg.1 for ; Thu, 25 May 2017 21:25:59 -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=7fA+UH5Fzt1NoNX3u3NBgYqkY4zCG2UCFbRsN7CuKiM=; b=hX37hLW9rzP2pnJPjfK57QTA1gbeYNTS9JGkEdcuLf7ZbA70uuM/rimjxLaO9skN1A vnCjOa+asIbKIJ197YBNLLh8K5k+9RGec9A/Ehx9ZehuLkn9QtY528gu8F0tVM9BGMN9 FubnmjokLEMJZhS0Xf31dpA9M9l4WLsjdG034= 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=7fA+UH5Fzt1NoNX3u3NBgYqkY4zCG2UCFbRsN7CuKiM=; b=IbYJ0YVCBo3rsy3oeCbDgPFd+Z9RCdexyIjjwAyHs5pJo+K+IBz6+VC0ILNwYVBEe6 7lTYLQh3wJbZjoQ3IvI1M8dxjIoX8t+UKHKLxrHNmysq4h0U8xgZiojXMMDZ2lhpg3iL GZOVQLdcrlufK/nzW6Bt2CxfCZhygH9WCgaFzcszFDG7kiICEIlqb4ONLVwZB7k5hLE3 6wouA/Avd0vnhNUxyjBMkKLIMPtFDt5q3ky2CYS0mrkenYzSXD8/HcrTXZIdkBrtfQ// tK61izuSMtOOdRZNvoXDahWRSNM/9O7hcpxlm41PEJyNEHX190Zs/OIBoH7D5h1bDPqm X3JQ== X-Gm-Message-State: AODbwcAeXtnjyUuOwLo4FBCe88MU1f1ddyKNT8fQjGPy/OzqfRnBbfcS kY5w0w03mj9LwNSB X-Received: by 10.28.132.210 with SMTP id g201mr531167wmd.26.1495772758674; Thu, 25 May 2017 21:25:58 -0700 (PDT) Received: from polaris.localnet (bzq-84-109-69-99.cablep.bezeqint.net. [84.109.69.99]) by smtp.gmail.com with ESMTPSA id t76sm12058275wme.16.2017.05.25.21.25.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 21:25:57 -0700 (PDT) From: Gregory Etelson To: "Lu, Wenzhuo" Cc: "dev@dpdk.org" , "users@dpdk.org" , "Yigit, Ferruh" Date: Fri, 26 May 2017 07:25:55 +0300 Message-ID: <2807341.pETrNvth7P@polaris> Organization: Weka.IO In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093B5BCE34@shsmsx102.ccr.corp.intel.com> References: <8509342.3MbcxIPMKs@polaris> <149580724.I1KizxjscO@polaris> <6A0DE07E22DDAD4C9103DF62FEBC09093B5BCE34@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: Fri, 26 May 2017 04:25:59 -0000 Hello, I'll update the code. Thank you. Regards, Gregory Hi Gregory, I think so. For example, In kernel driver, you can find there=E2=80=99s a m= essage that=E2=80=99s used for PF to notify VF when the link state changes. =20 =20 Best regards Wenzhuo Lu =20 *From:* Gregory Etelson [mailto:gregory@weka.io]=20 *Sent:* Thursday, May 25, 2017 2:03 PM *To:* Lu, Wenzhuo *Cc:* dev@dpdk.org; users@dpdk.org; Yigit, Ferruh *Subject:* Re: IXBGE VF: link state detection =20 Hello, In that case if I need reliable link state detection the only option is PF link verification. Is it so ? Thank you. Regards, Gregory On Thursday, 25 May 2017 08:44:56 IDT Lu, Wenzhuo wrote: Hi Gregory, Yes, I remember i40e kernel driver has the watchdog too. I guess maybe all = the NICs=E2=80=99 kernel driver has the similar mechanism. Not sure as I ha= ven=E2=80=99t checked J =20 =20 Best regards Wenzhuo Lu =20 *From:* Gregory Etelson [mailto:gregory@weka.io[1]]=20 *Sent:* Thursday, May 25, 2017 1:22 PM *To:* Lu, Wenzhuo *Cc:* dev@dpdk.org[2]; users@dpdk.org[3]; Yigit, Ferruh *Subject:* Re: IXBGE VF: link state detection =20 Hello, What about i40e VF PMD ? Does it have reliable link state monitoring ? Thank you. Regards, Gregory On Thursday, 25 May 2017 08:01:00 IDT Lu, Wenzhuo wrote: Hi Gregory, The mechanism is different. Kernel driver has a watchdog to check the link = state periodically. So, it can reset the link automatically. =20 =20 Best regards Wenzhuo Lu =20 *From:* Gregory Etelson [mailto:gregory@weka.io[1]]=20 *Sent:* Thursday, May 25, 2017 11:45 AM *To:* Lu, Wenzhuo *Cc:* dev@dpdk.org[2]; users@dpdk.org[3]; Yigit, Ferruh *Subject:* Re: IXBGE VF: link state detection =20 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[1]]=20 *Sent:* Wednesday, May 24, 2017 5:50 PM *To:* dev@dpdk.org[2] *Cc:* users@dpdk.org[3]; 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 =20 =20 =20 =2D------- [1] mailto:gregory@weka.io [2] mailto:dev@dpdk.org [3] mailto:users@dpdk.org