[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] [PATCH v4] content: Introduce VIRTIO_NET_F_STANDBY feature
On 10/10/2018 7:40 AM, Michael S. Tsirkin wrote:
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?
For an untrusted VF, MAC address is assigned by the management layer and is set via ndo_set_vf_mac() call to the PF on the hypervisor. This does cause the MAC RX filter to be programmed immediately. If possible we could delay setting the MAC RX filter until the device is guest visible, but before the driver is loaded. If the VF driver comes up with a random mac before the MAC address is set via PF, it will require a VF reset to get the right MAC which also would also result in downtime.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]