On Tue, 19 Dec 2017 12:44:25 -0800, Stephen Hemminger wrote: > On Tue, 19 Dec 2017 12:32:34 -0800 > Jakub Kicinski <kubak...@wp.pl> wrote: > > > On Tue, 19 Dec 2017 11:35:37 -0800, Stephen Hemminger wrote: > > > Rename the VF device to ethX_vf based on the ethX as the > > > synthetic device. This eliminates the need for delay on setup, > > > and the PCI (udev based) naming is not reproducible on Hyper-V > > > anyway. The name of the VF does not matter since all control > > > operations take place the primary device. It does make the > > > user experience better to associate the names. > > > > > > Based on feedback from all.systems.go talk. > > > The downside is that it requires exporting a symbol from netdev > > > core which makes it harder to backport. > > > > > > Signed-off-by: Stephen Hemminger <sthem...@microsoft.com> > > > > Why do you have to name the devices in the kernel space in the first > > place? :/ Why don't upstream the correct change to biosdevname like > > hardware vendors do? > > biosdevname is dead, gone and wouldn't work on Azure (it dumpster dives in > /dev/mem).
Hm, I haven't worked on biosdevname myself, but AFAIU it also falls back to information from the PCI VPD, which could be populated by the hypervisor. > I assume you mean the modern application is udev, and it works but the name > is meaningless > because it based of synthetic PCI information. The PCI host adapter is > simulated > for pass through devices. Names like enp12s0. > > Since every passthrough VF device on Hyper-V/Azure has a matching synthetic > network device with same mac address. It is best to have the relationship > shown in the name. How about we make the VF drivers expose "vf" as phys_port_name? Then systemd/udev should glue that onto the name regardless of how the VF is used. > > Your VF setup is really _not_ special, I don't understand why we are > > OK with ignoring the standard practices. Real enterprise distroes > > are very careful never to break the naming of interfaces and they keep > > the naming policy in user space. Playing tricks in the kernel has every > > chance of breaking existing user setups. > > Actually, Systemd folks said "naming policy is in userspace only because > kernel can't get it right". Also there is no uniformity in userspace > there are at least 5 systems trying to do network setup. And most of > them depend on eth0 (yes still). Fixing userspace is impossible.
