RE: [PATCH V3,net-next, 0/3] Add vmbus dev_num and allow netvsc probe options

[Haiyang Zhang]

> -----Original Message-----
> From: David Miller <davem@xxxxxxxxxxxxx>
> Sent: Thursday, January 2, 2020 7:30 PM
> To: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>
> Cc: sashal@xxxxxxxxxx; linux-hyperv@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx;
> KY Srinivasan <kys@xxxxxxxxxxxxx>; Stephen Hemminger
> <sthemmin@xxxxxxxxxxxxx>; olaf@xxxxxxxxx; vkuznets
> <vkuznets@xxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH V3,net-next, 0/3] Add vmbus dev_num and allow netvsc
> probe options
> 
> From: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>
> Date: Tue, 31 Dec 2019 14:13:31 -0800
> 
> > Add dev_num for vmbus device based on channel offer sequence.
> > User programs can use this number for nic naming.
> > Async probing option is allowed for netvsc. Sync probing is still the
> > default.
> 
> I don't like this at all, sorry.
> 
> If 4 devices get channels we will have IDs 1, 2, 3, 4.
> 
> Then if channel 3 is taken down, the next one will get 3 which is not in order
> any more.
> 
> It is not even clear what semantics these numbers have in any particular
> sequence or probe situation.
> 
> You have to use something more persistent across boots to number and strictly
> identify these virtual devices.
> 
> I'm not applying this.

The idea of this patch set is to make the naming of async probing same as that
in sync probing.

So, the semantics of this dev_num is actually same as the default "eth%d" naming --
	"Find the smallest number >=0, which is not in use."

In cases:
1) There is no hot add/remove devices in current boot, this scheme does provide 
persistent dev_num across reboot, because Hyper-V hosts offer the primary channels
in order. So the results based on this number with async probing will be the same 
as existing Sync probing.

2) If there is hot add/remove devices, this scheme generates the same results (when
user program use dev_num)  as the default naming mode -- by using the smallest
available number N in the format ethN.

In case of hot add/remove of virtual NICs, the removed NIC are gone, and the newly 
added NIC is a completely new virtual device with new device instance UUID. So if we 
don't reuse the previous numbers, the device name ethN will grow unbounded. For 
example, hot add/remove a virtual NIC 100 times, you will have a name like eth100. This 
not what the default naming scheme does, and we are not doing it for dev_num here 
either.

So the semantics is: "Find smallest number >=0, and not in use".

But if any customer wants to have a 1:1 mapping between the UUID and device name, they
can still implement that in user mode... And that's why this patch set doesn't change
the kernel naming from driver -- it just provides a new variable, "dev_num", so user 
mode program has the option to use it in async mode with knowledge of the channel
offer sequence.

Thanks,
- Haiyang