[prev in list] [next in list] [prev in thread] [next in thread] 

List:       systemd-devel
Subject:    Re: [systemd-devel] Better network naming on Hyper-V/Azure?
From:       Haiyang Zhang <haiyangz () microsoft ! com>
Date:       2020-01-16 19:08:56
Message-ID: MN2PR21MB13756FB53D00517E5510448CCA360 () MN2PR21MB1375 ! namprd21 ! prod ! outlook ! com
[Download RAW message or body]



> -----Original Message-----
> From: Lennart Poettering <lennart@poettering.net>
> Sent: Monday, January 13, 2020 4:18 AM
> To: Haiyang Zhang <haiyangz@microsoft.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>; systemd-
> devel@lists.freedesktop.org; Michael Kelley <mikelley@microsoft.com>
> Subject: Re: [systemd-devel] Better network naming on Hyper-V/Azure?
> 
> On Fr, 10.01.20 16:17, Haiyang Zhang (haiyangz@microsoft.com) 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.

Thanks for your suggestions!
So my implementation will keep the naming in kernel driver (netvsc). 

1) The netvsc's probe_type will be set to PROBE_DEFAULT_STRATEGY, 
so user can either continue with the current sync-probing by default, 
or use module/kernel cmdline option to enable Async-probing if other 
devices, such as DDA or SRIOV/VF NICs are configured to be named 
in different space (enP*, etc.) by systemd.

2) If Async-probing option is in use, netvsc driver will use the dev_num 
based on VMBus offer sequence. It will be the smallest available ethN 
format, which is the same result as the current sync-probing result.

3) My proposal is that Async probing has the same naming as sync 
probing. In case of hot add/remove, the names may be reused. The 
names may change after hot add/remove then reboot once. But the 
names will be stable in further reboots. It is the same behavior as 
current code (sync probing).

Thanks,
- Haiyang


_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[prev in list] [next in list] [prev in thread] [next in thread]