On Wed, Dec 20, 2017 at 8:52 PM, Jakub Kicinski <kubakici@xxxxx> wrote: > On Wed, 20 Dec 2017 18:16:30 -0800, Siwei Liu wrote: >> > The plan is to remove the delay and do the naming in the kernel. >> > This was suggested by Lennart since udev is only doing naming policy >> > because kernel names were not repeatable. >> > >> > This makes the VF show up as "ethN_vf" on Hyper-V which is user friendly. >> > >> > Patch is pending. >> >> While it's good to show VF with specific naming to indicate >> enslavement, I wonder wouldn't it be better to hide this netdev at all >> from the user space? IMHO this extra device is useless when being >> enslaved and we may delegate controls (e.g. ethtool) over to the >> para-virtual device instead? That way it's possible to eliminate the >> possibility of additional udev setup or modification? >> >> I'm not sure if this is consistent with Windows guest or not, but I >> don't find it _Linux_ user friendly that ethtool doesn't work on the >> composite interface any more, and I have to end up with finding out >> the correct enslaved VF I must operate on. > > Hiding "low level" netdevs comes up from time to time, and is more > widely applicable than just to VF bonds. We should find a generic > solution to that problem. Wholeheartedly agreed. Be it a generic virtual bond or virtio-net specific one, there should be some common code between netvsc and virtio for this type of work. For avoiding duplicated bugs, consistent (Linux) user experience, future code refactoring/management, and whatever... One thing worth to note is that, unlike the Hyper-V netvsc backend there's currently no equivalent (fine-grained) Linux ndo_* driver interface that is able to move around MAC address/VLAN filters at run-time specifically. The OID_RECEIVE_FILTER_MOVE_FILTER request I mean. That translates to one substantial difference in VF plumbing/unplumbing sequence: you cannot move the MAC address around to paravirt device until VF is fully unplugged out of the guest OS. I don't know what backend changes to be proposed for virtio-net as helper, but the common code needs to work with both flavors of data path switching backends and do its job correctly. Regards, -Siwei _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
