On Fri, 8 Jun 2018 16:44:12 -0700, Siwei Liu wrote: > >> I have a somewhat different view regarding IFF_HIDDEN. The purpose of > >> that flag, as well as the 1-netdev model, is to have a means to > >> inherit the interface name from the VF, and to eliminate playing hacks > >> around renaming devices, customizing udev rules and et al. Why > >> inheriting VF's name important? To allow existing config/setup around > >> VF continues to work across kernel feature upgrade. Most of network > >> config files in all distros are based on interface names. Few are MAC > >> address based but making lower slaves hidden would cover the rest. And > >> most importantly, preserving the same level of user experience as > >> using raw VF interface once getting all ndo_ops and ethtool_ops > >> exposed. This is essential to realize transparent live migration that > >> users dont have to learn and be aware of the undertaken. > > > > Inheriting the VF name will fail in the migration scenario. > > It is perfectly reasonable to migrate a guest to another machine where > > the VF PCI address is different. And since current udev/systemd model > > is to base network device name off of PCI address, the device will change > > name when guest is migrated. > > > The scenario of having VF on a different PCI address on post migration > is essentially equal to plugging in a new NIC. Why it has to pair with > the original PV? A sepearte PV device should be in place to pair the > new VF.
IMHO it may be a better idea to look at the VF as acceleration for the PV rather than PV a migration vehicle from the VF. Hence we should continue to follow the naming of PV, like the current implementation does implicitly by linking to PV's struct device.
