From: Stephen Hemminger <stephen@networkplumber.org>
To: "Benoit Ganne (bganne)" <bganne@cisco.com>
Cc: "users@dpdk.org" <users@dpdk.org>
Subject: Re: [dpdk-users] CX4-Lx VF link status in Azure
Date: Thu, 26 Mar 2020 10:57:53 -0700 [thread overview]
Message-ID: <20200326105753.5d1a7e05@hermes.lan> (raw)
In-Reply-To: <CH2PR11MB4327C92B0AF7B4B6E1DEAA69C1CF0@CH2PR11MB4327.namprd11.prod.outlook.com>
On Thu, 26 Mar 2020 14:26:56 +0000
"Benoit Ganne (bganne)" <bganne@cisco.com> wrote:
> Hi Stephen,
>
> > Is this with netvsc PMD or failsafe PMD?
>
> I am using failsafe PMD using the string "--vdev net_vdev_netvsc0,iface=eth1" etc. as mentioned here: https://docs.microsoft.com/en-us/azure/virtual-network/setup-dpdk
> I checked with gdb what are the underlying devices and there is 1 mlx5 and 1 tap instance as expected.
> To get the link state, the call stack is rte_eth_link_get_nowait() -> fs_link_update() -> mlx5_link_update() -> mlx5_link_update_unlocked_gs() which looks good to me.
> The link state update fails in mlx5_link_update_unlocked_gs() because the link speed retrieved from the Linux kernel driver is '0' (unknown). Note that ethtool and '/sys/class/net/<iface>/speed' also fails to report the link speed (but not the link status).
> At the end of the day, maybe the Linux kernel driver should report a link speed, however I think it should not prevent DPDK to update the link state (up/down).
> Just removing the offending test makes everything working again but I do not think it is the correct solution: I do not know why this test was added for.
>
> > You maybe missing this patch, which is only in current development branch.
> > Since it is tagged for stable, it should end up in later LTS versions as
> > well 18.11.X and 19.11.X.
>
> I tried the patch but it did not solve the issue. I think it is expected as I am using failsafe with tap and not netvsc, correct?
>
> Best
> ben
Is the Mellanox device being brought up by the base kernel setup?
I find that for Mellanox the device has to be started from kernel (like ip)
and DPDK doesn't do itself.
next prev parent reply other threads:[~2020-03-26 17:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 19:07 Benoit Ganne (bganne)
2020-03-25 21:32 ` Stephen Hemminger
2020-03-25 22:48 ` Stephen Hemminger
2020-03-26 14:26 ` Benoit Ganne (bganne)
2020-03-26 17:57 ` Stephen Hemminger [this message]
2020-03-26 18:27 ` Benoit Ganne (bganne)
2020-03-26 18:52 ` Thomas Monjalon
2020-03-26 19:00 ` Benoit Ganne (bganne)
2020-03-26 20:09 ` Mark Bloch
2020-03-26 20:40 ` Thomas Monjalon
2020-03-26 21:31 ` Thomas Monjalon
2020-03-27 10:02 ` Benoit Ganne (bganne)
2020-03-27 10:13 ` Thomas Monjalon
2020-03-27 17:26 ` Benoit Ganne (bganne)
2020-03-27 22:34 ` Thomas Monjalon
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=20200326105753.5d1a7e05@hermes.lan \
--to=stephen@networkplumber.org \
--cc=bganne@cisco.com \
--cc=users@dpdk.org \
/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).