From: Stephen Hemminger <[email protected]> Date: Tue, 26 Dec 2017 13:51:43 -0800
> On Tue, 26 Dec 2017 12:25:12 -0500 (EST) > David Miller <[email protected]> wrote: > >> From: Stephen Hemminger <[email protected]> >> Date: Wed, 20 Dec 2017 14:33:23 -0800 >> >> > Since commit 6123c66854c1 ("netvsc: delay setup of VF device") >> > the automatic bring up of the VF is delayed to allow userspace (udev) >> > a chance to rename the device. This delay is problematic because >> > it delays boot and may not be long enough for some cases. >> > >> > Instead, use the rename can be used to trigger the next step >> > in setup to happen immediately. >> > >> > The VF initialization sequence now looks like: >> > * hotplug causes VF network device probe to create network device >> > * netvsc notifier joins VF with netvsc and schedules VF to be >> > setup after timer expires >> > * udev in userspace renames device >> > * if netvsc notifier detects rename, it can cancel timer >> > and do immediate setup >> > >> > The delay can also be increased to allow for slower rules. >> > Still need the delayed work to handle the case where rename is >> > not done. >> > >> > Signed-off-by: Stephen Hemminger <[email protected]> >> >> I'm still seriously perplexed by this whole situation. > > See state diagram below > >> Why can't you bring up a VF interface simply because of a text string >> used to reffered to it? > > VF network device can not have its name changed if up. > The network device kernel API does not allow name change of network > device that is up. There was a patch from Vitaly to allow this, but it > was deemed to be too risky. > > https://patchwork.ozlabs.org/patch/799646/ Thank you for the state diagram. I still, unfortunately, don't see the problem. If userland changes the name of the VF device, then they will change it before bringing the VF device up. Thanks for your patience with me.
