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

["Samudrala, Sridhar" <sridhar.samudrala@intel.com>]

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.


> 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