Re: [RFC] hv_netvsc: automatically name slave VF network device

On Tue, 19 Dec 2017 14:24:52 -0800
Jakub Kicinski [off-list ref] wrote:

On Tue, 19 Dec 2017 14:06:59 -0800, Stephen Hemminger wrote:

quoted

quoted

quoted

quoted

quoted

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.