From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH] hv_netvsc: update VF after name has changed. Date: Tue, 26 Dec 2017 17:11:19 -0500 (EST) Message-ID: <20171226.171119.1016371414270103500.davem@davemloft.net> References: <20171220223323.21125-1-sthemmin@microsoft.com> <20171226.122512.2094828192772967433.davem@davemloft.net> <20171226135143.639c8476@xeon-e3> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, sthemmin@microsoft.com To: stephen@networkplumber.org Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:57982 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750822AbdLZWLZ (ORCPT ); Tue, 26 Dec 2017 17:11:25 -0500 In-Reply-To: <20171226135143.639c8476@xeon-e3> Sender: netdev-owner@vger.kernel.org List-ID: From: Stephen Hemminger Date: Tue, 26 Dec 2017 13:51:43 -0800 > On Tue, 26 Dec 2017 12:25:12 -0500 (EST) > David Miller wrote: > >> From: Stephen Hemminger >> 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 >> >> 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.