DPDK usage discussions
 help / color / mirror / Atom feed
From: Gregory Etelson <gregory@weka.io>
To: "Lu, Wenzhuo" <wenzhuo.lu@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, "users@dpdk.org" <users@dpdk.org>,
	"Yigit, Ferruh" <ferruh.yigit@intel.com>
Subject: Re: [dpdk-users] IXBGE VF: link state detection
Date: Thu, 25 May 2017 08:22:23 +0300	[thread overview]
Message-ID: <3497961.mUtAKJcRhq@polaris> (raw)
In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093B5BC9D5@shsmsx102.ccr.corp.intel.com>

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.
 
 
Best regards
Wenzhuo Lu
 
*From:* Gregory Etelson [mailto:gregory@weka.io] 

*Sent:* Thursday, May 25, 2017 11:45 AM

*To:* Lu, Wenzhuo

*Cc:* dev@dpdk.org; users@dpdk.org; Yigit, Ferruh

*Subject:* Re: IXBGE VF: link state detection
 
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’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[1]] 

*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
 
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 
  



--------
[1] mailto:gregory@weka.io
[2] mailto:dev@dpdk.org
[3] mailto:users@dpdk.org

  reply	other threads:[~2017-05-25  5:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-24  9:50 Gregory Etelson
2017-05-24 13:26 ` [dpdk-users] [dpdk-dev] " Olivier Matz
2017-05-25  3:48   ` Gregory Etelson
2017-05-25  0:56 ` [dpdk-users] " Lu, Wenzhuo
2017-05-25  3:45   ` Gregory Etelson
2017-05-25  5:01     ` Lu, Wenzhuo
2017-05-25  5:22       ` Gregory Etelson [this message]
2017-05-25  5:44         ` Lu, Wenzhuo
2017-05-25  6:03           ` Gregory Etelson
2017-05-26  0:54             ` Lu, Wenzhuo
2017-05-26  4:25               ` Gregory Etelson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3497961.mUtAKJcRhq@polaris \
    --to=gregory@weka.io \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=users@dpdk.org \
    --cc=wenzhuo.lu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).