On Tue, 19 Dec 2017 13:18:16 -0800 Jakub Kicinski <kubak...@wp.pl> wrote:
> 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. VPD never had any useful standard are info. The rules used by udev come off sysfs, see: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ > > > 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. One of the goals was not to modify in any way other drivers (like VF). > > > > 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.
