From: Stephen Hemminger <stephen@networkplumber.org>
To: David Evans <davidjoshuaevans@gmail.com>
Cc: qiming.yang@intel.com, dev@dpdk.org
Subject: Re: [dpdk-dev] to wait or not to wait.. DPDK & OVS ixgbe with fibre disconnected
Date: Fri, 31 Aug 2018 08:12:05 -0700 [thread overview]
Message-ID: <20180831081205.7a588890@xeon-e3> (raw)
In-Reply-To: <CAB8HAh6nJmVn2SbssnyxwhvYqRvcjqYKaVaDxYHt2YDJ46TzYg@mail.gmail.com>
On Wed, 29 Aug 2018 16:57:55 -0500
David Evans <davidjoshuaevans@gmail.com> wrote:
> Hi!
>
> We have a thread running on ovs discuss. - Can you contribute?
>
> regarding ixgbe_ethdev.c
>
> ixgbe_dev_link_update() doesn't honour wait_to_complete flag always.
>
> Basically, where you have 'wait_to_complete' set to 0, we are still having
> to wait sometimes
> Dpdk is always attempting setup if intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG
> Which happens if you unplug fibre, or don't plug it in.
>
> is there a better way to handle this? It is causing OVS to get stuck
> busy... on the thread that calls this.
>
> eg:
> in line 4000 - ixgbe_setup_link(hw,speed,true)
>
> if ((intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) &&
> ixgbe_get_media_type(hw) == ixgbe_media_type_fiber) {
> speed = hw->phy.autoneg_advertised;
> if (!speed)
> ixgbe_get_link_capabilities(hw, &speed, &autoneg);
> ixgbe_setup_link(hw, speed, true);
> }
>
>
> or also...
>
> #0 rte_delay_us_block (us=100000) at
> /usr/src/debug/dpdk-17.11.3/lib/librte_eal/common/eal_common_timer.c:59
> #1 0x00007f548f79ceec in ixgbe_setup_mac_link_multispeed_fiber
> (hw=0x7f543fc2f680, speed=128, autoneg_wait_to_complete=0) at
> /usr/src/debug/dpdk-17.11.3/drivers/net/ixgbe/base/ixgbe_common.c:5155
> #2 0x00007f548f7c2cb2 in ixgbe_dev_link_update_share (vf=0,
> wait_to_complete=0, dev=0x7f549492d480 <rte_eth_devices+82560>) at
> /usr/src/debug/dpdk-17.11.3/drivers/net/ixgbe/ixgbe_ethdev.c:4000
> #3 ixgbe_dev_link_update (dev=0x7f549492d480 <rte_eth_devices+82560>,
> wait_to_complete=0) at
> /usr/src/debug/dpdk-17.11.3/drivers/net/ixgbe/ixgbe_ethdev.c:4070
>
> Thanks so much
>
> Dave.
In my experience the wait flag is pretty useless. It means "wait until link is up"
which means the wait loop happens in the driver when it is better handled by the
application. Also, many drivers do not implement it.
next prev parent reply other threads:[~2018-08-31 15:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-29 21:57 David Evans
2018-08-31 15:12 ` Stephen Hemminger [this message]
2018-10-31 1:42 ` Zhao1, Wei
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=20180831081205.7a588890@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=davidjoshuaevans@gmail.com \
--cc=dev@dpdk.org \
--cc=qiming.yang@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).