On 6/5/2018 2:52 PM, Stephen Hemminger wrote:
On Tue, 5 Jun 2018 22:38:43 +0300 "Michael S. Tsirkin" <m...@redhat.com> wrote:See: https://patchwork.ozlabs.org/patch/851711/Let me try to summarize that: You wanted to speed up the delayed link up. You had an idea to additionally take link up when userspace renames the interface (standby one which is also the failover for netvsc). But userspace might not do any renames, in which case there will still be the delay, and so this never got applied. Is this a good summary? Davem said delay should go away completely as it's not robust, and I think I agree. So I don't think we should make all failover users use delay. IIUC failover kept a delay option especially for netvsc to minimize the surprise factor. Hopefully we can come up with something more robust and drop that option completely.The timeout was the original solution to how to complete setup after userspace has had a chance to rename the device. Unfortunately, the whole network device initialization (cooperation with udev and userspace) is a a mess because there is no well defined specification, and there are multiple ways userspace does this in old and new distributions. The timeout has its own issues (how long, handling errors during that window, what if userspace modifies other device state); and open to finding a better solution. My point was that if name change can not be relied on (or used) by netvsc, then we can't allow it for net_failover either.
I think the push back was with the usage of the delay, not bringing up the primary/standby device in the name change event handler. Can't netvsc use this mechanism instead of depending on the delay?
