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