On Tue, 19 Dec 2017 14:06:59 -0800, Stephen Hemminger wrote: > > > > > 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). > > > > Why? Do you have out-of-tree drivers you can't change or some such? > > This needs to work on enterprise distributions; plus it is not good > practice to introduce random changes into partners like Mellanox > drivers.
Are we talking about Linux or Windows kernel here? I don't think this requires hypervisor changes? The notion of a "partner" and changing drivers by people who are not employed by a vendor being bad practice sounds entirely foreign to me. If we agree that marking VF interfaces is useful (and I think it is) then we should mark them always, not only when they are enslaved to a magic bond. And the natural way of doing that seems to be phys_port_name.
