> From: Haiyang Zhang <haiya...@microsoft.com> > Sent: Friday, April 16, 2021 10:11 AM > > From: Stephen Hemminger <step...@networkplumber.org> > > > ... > > > @@ -2319,8 +2320,17 @@ static struct net_device > > *get_netvsc_byslot(const struct net_device *vf_netdev) > > > if (!ndev_ctx->vf_alloc) > > > continue; > > > > > > - if (ndev_ctx->vf_serial == serial) > > > - return hv_get_drvdata(ndev_ctx->device_ctx); > > > + if (ndev_ctx->vf_serial != serial) > > > + continue; > > > + > > > + ndev = hv_get_drvdata(ndev_ctx->device_ctx); > > > + if (ndev->addr_len != vf_netdev->addr_len || > > > + memcmp(ndev->perm_addr, vf_netdev->perm_addr, > > > + ndev->addr_len) != 0) > > > + continue; > > > + > > > + return ndev; > > > + > > > } > > > > > > netdev_notice(vf_netdev, > > > > > > This probably should be a separate patch. > > I think it is trying to address the case of VF discovery in Hyper-V/Azure > > where > > the reported > > VF from Hypervisor is bogus or confused. > > This is for the Multi vPorts feature of MANA driver, which allows one VF to > create multiple vPorts (NICs). They have the same PCI device and same VF > serial number, but different MACs. > > So we put the change in one patch to avoid distro vendors missing this > change when backporting the MANA driver. > > Thanks, > - Haiyang
The netvsc change should come together in the same patch with this VF driver, otherwise the multi-vPorts functionality doesn't work properly. The netvsc change should not break any other existing VF drivers, because Hyper-V NIC SR-IOV implementation requires the the NetVSC network interface and the VF network interface should have the same MAC address, otherwise things won't work. Thanks, Dexuan
