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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 10.01.20 16:17, Haiyang Zhang (haiyangz@xxxxxxxxxxxxx) wrote:

> > 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

Then deal with it in the kernel. Allocating from the same ethN
namespace is always going to be racy if both kernel and userspace do
it.

That's why the names userspace generally picks for stable Ethernet
interfaces start with "en" followed by some stable suffix of a kind,
under the assumption the kernel will not allocate from that namespace.

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

If you have any other driver register network interfaces on your
kernel than your whole enumeration will go wrong though. If you
tightly control which drivers exist in your environment you might get
away with taking ownership of the ethN namespace entirely from your
own driver and manage it fully.

Lennart

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