[dpdk-users] CX4-Lx VF link status in Azure

[Stephen Hemminger]

On Thu, 26 Mar 2020 14:26:56 +0000
"Benoit Ganne (bganne)" <bganne at 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.