From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH net] failover: eliminate callback hell Date: Wed, 6 Jun 2018 15:19:30 +0300 Message-ID: <20180606151019-mutt-send-email-mst@kernel.org> References: <20180605034231.31610-1-sthemmin@microsoft.com> <20180605211927-mutt-send-email-mst@kernel.org> <20180605115305.502a7ebb@xeon-e3> <20180605221049-mutt-send-email-mst@kernel.org> <20180605145222.477e5ae8@xeon-e3> <20180605205118.439a7873@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Samudrala, Sridhar" , kys@microsoft.com, haiyangz@microsoft.com, davem@davemloft.net, netdev@vger.kernel.org, Stephen Hemminger To: Stephen Hemminger Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:37910 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751714AbeFFMTb (ORCPT ); Wed, 6 Jun 2018 08:19:31 -0400 Content-Disposition: inline In-Reply-To: <20180605205118.439a7873@xeon-e3> Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Jun 05, 2018 at 08:51:18PM -0700, Stephen Hemminger wrote: > > 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? > > > > > > The patch that was rejected for netvsc was about using name change. So failover is now doing exactly what you wanted netvsc to do. Rather than reverting everyone to old behaviour how about using more pieces from failover? > Also, you can't depend on name change; you still need a timer. Not all distributions > change name of devices. So failover chose not to implement the delayed open so far. If it does I suspect we'll have to keep it around forever - kind of like netvsc seems to be stuck with it. But let's see if there's enough actual demand from people running ancient distros with latest kernels to even start looking for a solution for failover. And this kind of behaviour change really should be split out so we can discuss it separately. > Or user has blocked that by udev rules. Don't do that then? -- MST