From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jakub Kicinski <kubakici@wp.pl>
Subject: Re: [PATCH net] failover: eliminate callback hell
Date: Fri, 8 Jun 2018 18:29:33 -0700
Message-ID: <20180608182933.5a8150e7@cakuba.netronome.com>
References: <20180605034231.31610-1-sthemmin@microsoft.com>
        <20180606072512.GA2289@nanopsycho.orion>
        <20180606151955-mutt-send-email-mst@kernel.org>
        <20180606142447.3c5072d8@xeon-e3>
        <CADGSJ201TaacZhRTgQZC+a3c5fu8JkHcGifGTfbFQzyocCJxVg@mail.gmail.com>
        <20180608161801.64afda65@xeon-e3>
        <CADGSJ20sq8AmW34Z7w0JrTg6=YnKaM3Hq5R3TfhAH5BkuR2pqA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Stephen Hemminger <stephen@networkplumber.org>,
        "Michael S. Tsirkin" <mst@redhat.com>,
        Jiri Pirko <jiri@resnulli.us>, kys@microsoft.com,
        haiyangz@microsoft.com, David Miller <davem@davemloft.net>,
        "Samudrala, Sridhar" <sridhar.samudrala@intel.com>,
        Netdev <netdev@vger.kernel.org>,
        Stephen Hemminger <sthemmin@microsoft.com>
To: Siwei Liu <loseweigh@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mx3.wp.pl ([212.77.101.10]:20959 "EHLO mx3.wp.pl"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751120AbeFIB3l (ORCPT <rfc822;netdev@vger.kernel.org>);
        Fri, 8 Jun 2018 21:29:41 -0400
In-Reply-To: <CADGSJ20sq8AmW34Z7w0JrTg6=YnKaM3Hq5R3TfhAH5BkuR2pqA@mail.gmail.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Fri, 8 Jun 2018 16:44:12 -0700, Siwei Liu wrote:
> >> I have a somewhat different view regarding IFF_HIDDEN. The purpose of
> >> that flag, as well as the 1-netdev model, is to have a means to
> >> inherit the interface name from the VF, and to eliminate playing hacks
> >> around renaming devices, customizing udev rules and et al. Why
> >> inheriting VF's name important? To allow existing config/setup around
> >> VF continues to work across kernel feature upgrade. Most of network
> >> config files in all distros are based on interface names. Few are MAC
> >> address based but making lower slaves hidden would cover the rest. And
> >> most importantly, preserving the same level of user experience as
> >> using raw VF interface once getting all ndo_ops and ethtool_ops
> >> exposed. This is essential to realize transparent live migration that
> >> users dont have to learn and be aware of the undertaken.  
> >
> > Inheriting the VF name will fail in the migration scenario.
> > It is perfectly reasonable to migrate a guest to another machine where
> > the VF PCI address is different. And since current udev/systemd model
> > is to base network device name off of PCI address, the device will change
> > name when guest is migrated.
> >  
> The scenario of having VF on a different PCI address on post migration
> is essentially equal to plugging in a new NIC. Why it has to pair with
> the original PV? A sepearte PV device should be in place to pair the
> new VF.

IMHO it may be a better idea to look at the VF as acceleration for the
PV rather than PV a migration vehicle from the VF.  Hence we should
continue to follow the naming of PV, like the current implementation
does implicitly by linking to PV's struct device.