Re: Better network naming on Hyper-V/Azure?

[Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: Lennart Poettering <lennart@xxxxxxxxxxxxxx>
> Sent: Friday, January 10, 2020 10:55 AM
> To: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>
> Cc: Stephen Hemminger <stephen@xxxxxxxxxxxxxxxxxx>; systemd-
> devel@xxxxxxxxxxxxxxxxxxxxx; Michael Kelley <mikelley@xxxxxxxxxxxxx>
> Subject: Re:  Better network naming on Hyper-V/Azure?
> 
> On Fr, 10.01.20 15:37, Haiyang Zhang (haiyangz@xxxxxxxxxxxxx) wrote:
> 
> > > Hyper-V offers netvsc devices (synthetic NICs) in the same sequence across
> > > reboots, so eth0 ... ethN names will associate to the same vNIC every time
> > > with Sync-probing currently.
> > >
> > > But if in the future, we enable Async-probing, the naming may not
> persistent
> > > across reboots. In my patch set (not yet upstream), I added a new attribute
> > > (dev_num) in sysfs to keep track of the device channel offer sequence. So
> user
> > > mode program can have the option to use this attribute to name NICs, and
> > > generates the same results for Async-probing as Sync-probing does.
> >
> > Lennart and other systemd developers:
> >
> > Could you also comment on my proposal above? It's to keep the naming
> results
> > of Async-probing same as that of sync-probing.
> 
> I am not sure I follow fully, but if you intend to assign an index to
> each interface that the VM supervisor sets and that we should use to
> name the interface, then that sounds great to me.
> 
> However do note that we generally avoid stepping into the naming
> namespace of the kernel. i.e. if your intention to stabilize eth0,
> eth1, eth2 with that, we can't help you, that's generally racy since
> the kernel allocates other interfaces from that namespace too.
> 
> My guess is that this is a lot like SR-IOV slot number that we can
> already use to name interfaces, right? If so, supporting things the
> same way sounds totally OK.

Thanks for your explanation. We do want to use the ethN format, and want the 
results to be the same between Async and sync probing.

@Stephen Hemminger Since systemd needs to avoid stepping into the kernel 
ethN formatting, should we do the synthetic NIC naming inside kernel (netvsc 
driver)? 

In case of conflicting with other names, like DDA, or VF NICs, it will fall back to 
the first available ethN name. I know It's racy, but not worse than current 
situation -- even with sync-probing, the name may still be racing with DDA, or 
VF NICs. And this is already solvable by systemd which uses PCI slot naming, and
puts them into different naming formats.

Thanks,
- Haiyang

_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel