From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Samudrala, Sridhar" Subject: Re: [PATCH net] failover: eliminate callback hell Date: Wed, 6 Jun 2018 14:54:04 -0700 Message-ID: References: <20180605034231.31610-1-sthemmin@microsoft.com> <20180606072512.GA2289@nanopsycho.orion> <20180606151955-mutt-send-email-mst@kernel.org> <20180606142447.3c5072d8@xeon-e3> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Jiri Pirko , kys@microsoft.com, haiyangz@microsoft.com, davem@davemloft.net, netdev@vger.kernel.org, Stephen Hemminger To: Stephen Hemminger , "Michael S. Tsirkin" Return-path: Received: from mga17.intel.com ([192.55.52.151]:12623 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752354AbeFFVyF (ORCPT ); Wed, 6 Jun 2018 17:54:05 -0400 In-Reply-To: <20180606142447.3c5072d8@xeon-e3> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 6/6/2018 2:24 PM, Stephen Hemminger wrote: > On Wed, 6 Jun 2018 15:30:27 +0300 > "Michael S. Tsirkin" wrote: > >> On Wed, Jun 06, 2018 at 09:25:12AM +0200, Jiri Pirko wrote: >>> Tue, Jun 05, 2018 at 05:42:31AM CEST, stephen@networkplumber.org wrote: >>>> The net failover should be a simple library, not a virtual >>>> object with function callbacks (see callback hell). >>> Why just a library? It should do a common things. I think it should be a >>> virtual object. Looks like your patch again splits the common >>> functionality into multiple drivers. That is kind of backwards attitude. >>> I don't get it. We should rather focus on fixing the mess the >>> introduction of netvsc-bonding caused and switch netvsc to 3-netdev >>> model. >> So it seems that at least one benefit for netvsc would be better >> handling of renames. >> >> Question is how can this change to 3-netdev happen? Stephen is >> concerned about risk of breaking some userspace. >> >> Stephen, this seems to be the usecase that IFF_HIDDEN was trying to >> address, and you said then "why not use existing network namespaces >> rather than inventing a new abstraction". So how about it then? Do you >> want to find a way to use namespaces to hide the PV device for netvsc >> compatibility? >> > Netvsc can't work with 3 dev model. MS has worked with enough distro's and > startups that all demand eth0 always be present. And VF may come and go. > After this history, there is a strong motivation not to change how kernel > behaves. Switching to 3 device model would be perceived as breaking > existing userspace. I think it should be possible for netvsc to work with 3 dev model if the only requirement is that eth0 will always be present. With net_failover, you will see eth0 and eth0nsby OR with older distros eth0 and eth1.  It may be an issue if somehow there is userspace requirement that there can be only 2 netdevs, not 3 when VF is plugged. eth0 will be the net_failover device and eth0nsby/eth1 will be the netvsc device and the IP address gets configured on eth0. Will this be an issue? > > With virtio you can work it out with the distro's yourself. > There is no pre-existing semantics to deal with. > > For the virtio, I don't see the need for IFF_HIDDEN. > With 3-dev model as long as you mark the PV and VF devices > as slaves, then userspace knows to leave them alone. Assuming userspace > is already able to deal with team and bond devices. > Any time you introduce new UAPI behavior something breaks. > > On the rename front, I really don't care if VF can be renamed. And for > netvsc want to allow the PV device to be renamed. Udev developers want that > but have not found a stable/persistent value to expose to userspace > to allow it.