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 <m...@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-unsubscr...@lists.oasis-open.org > > > For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org > > > --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org