Re: [virtio-dev] [PATCH v4] content: Introduce VIRTIO_NET_F_STANDBY feature

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Oct 04, 2018 at 10:17:04PM -0700, Samudrala, Sridhar wrote:
> On 10/4/2018 5:03 PM, Siwei Liu wrote:
> > On Tue, Oct 2, 2018 at 5:43 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > On Tue, Oct 02, 2018 at 01:42:09AM -0700, Siwei Liu wrote:
> > > > The VF's MAC can be updated by PF/host on the fly at any time. One can
> > > > start with a random MAC but use group ID to pair device instead. And
> > > > only update MAC address to the real one when moving MAC filter around
> > > > after PV says OK to switch datapath.
> > > > 
> > > > Do you see any problem with this design?
> > > Isn't this what I proposed:
> > >          Maybe we can
> > >          start VF with a temporary MAC, then change it to a final one when guest
> > >          tries to use it. It will work but we run into fact that MACs are
> > >          currently programmed by mgmnt - in many setups qemu does not have the
> > >          rights to do it.
> > > 
> > > ?
> > > 
> > > If yes I don't see a problem with the interface design, even though
> > > implementation wise it's more work as it will have to include management
> > > changes.
> > I thought we discussed this design a while back:
> > https://www.spinics.net/lists/netdev/msg512232.html
> > 
> > ... plug in a VF with a random MAC filter programmed in prior, and
> > initially use that random MAC within guest. This would require:
> > a) not relying on permanent MAC address to do pairing during the
> > initial discovery, e.g. use the failover group ID as in this
> > discussion
> > b) host to toggle the MAC address filter: which includes taking down
> > the tap device to return the MAC back to PF, followed by assigning
> > that MAC to VF using "ip link ... set vf ..."
> > c) notify guest to reload/reset VF driver for the change of hardware MAC address
> > d) until VF reloads the driver it won't be able to use the datapath,
> > so very short period of network outage is (still) expected
> > 
> > though I still don't think this design can elimnate downtime. However,
> > it looks like as of today the MAC matching still haven't addressed the
> > datapath switching and error handling in a clean way.
> 
> I am not sure what is the issue with datapath switching with the net_failover solution.
> 
> Do you see any issues with the migration management layer to automate the steps
> that are listed in the example script in the documentation.
> https://www.kernel.org/doc/html/latest/networking/net_failover.html
> 
> Now that we are considering making the VF visible only when the standby negotiation
> is completed, i am not sure why we need a random MAC.
> 

The claim is that some pfs update MAC RX filter immediately once vf is
created, not when its driver attaches. That will mean on hot-plug there
is downtime until device is guest visible and driver initialized.

Can you confirm that isn't the case for intel cards?


> > As said, for
> > SR-IOV live migration on iSCSI root disk there will be a lot of
> > dancing parts going along the way, reliable network connectity and
> > dedicated handshakes are critical to this kind of setup.
> > 
> > -Siwei
> > 
> > > --
> > > MST
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > > 

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org