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