On Tue, 19 Dec 2017 14:24:52 -0800 Jakub Kicinski <kubak...@wp.pl> wrote:
> 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. Minor bug fixes sure, but changing semantics requires consultation. Vendors like Intel and Mellanox have code bases that feed upstream. > 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.
