Re: [PATCH] hv_netvsc: update VF after name has changed.

From: Stephen Hemminger <stephen@networkplumber.org>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, sthemmin@microsoft.com
Subject: Re: [PATCH] hv_netvsc: update VF after name has changed.
Date: Tue, 26 Dec 2017 15:46:48 -0800	[thread overview]
Message-ID: <20171226154648.1daad248@xeon-e3> (raw)
In-Reply-To: <20171226.171119.1016371414270103500.davem@davemloft.net>

On Tue, 26 Dec 2017 17:11:19 -0500 (EST)
David Miller <davem@davemloft.net> wrote:

> From: Stephen Hemminger <stephen@networkplumber.org>
> Date: Tue, 26 Dec 2017 13:51:43 -0800
> 
> > On Tue, 26 Dec 2017 12:25:12 -0500 (EST)
> > David Miller <davem@davemloft.net> wrote:
> >   
> >> From: Stephen Hemminger <stephen@networkplumber.org>
> >> 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 <sthemmin@microsoft.com>    
> >> 
> >> 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.

The requirement is to support several unmodified naive distributions.
All of these expect eth0 to be present and should not require configuration or
manipulation of the VF network device. This is why the bonding script method never
worked.

Userland is not responsible for bringing up the VF device. Most distributions leave
unknown devices alone, some use network manager which brings up everything it sees.
The netvsc device is responsible for having the state of the VF device track the state
of the master (netvsc) device.

> 
> Thanks for your patience with me.

No worries, this is not my favorite way of doing this either. The pure VF method used
by some other cloud providers is easier for userspace; but changing the host (and the
hardware FPGA) is not an option. This all just trying to work out
something practical with the API's available.