From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-4885-cohuck=redhat.com@lists.oasis-open.org Sender: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 76A1C985E3F for ; Fri, 5 Oct 2018 05:18:09 +0000 (UTC) References: <20180918093310-mutt-send-email-mst@kernel.org> <20180918151337.GA7432@vbusired-dt> <20180918111540-mutt-send-email-mst@kernel.org> <20180919230502-mutt-send-email-mst@kernel.org> <20180920220951-mutt-send-email-mst@kernel.org> <20180927121739-mutt-send-email-mst@kernel.org> <20181002083928-mutt-send-email-mst@kernel.org> From: "Samudrala, Sridhar" Message-ID: <42b5758f-3507-1d18-8fe1-83661ba0f998@intel.com> Date: Thu, 4 Oct 2018 22:17:04 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [virtio-dev] [PATCH v4] content: Introduce VIRTIO_NET_F_STANDBY feature To: Siwei Liu , "Michael S. Tsirkin" Cc: Venu Busireddy , Cornelia Huck , virtio-dev List-ID: On 10/4/2018 5:03 PM, Siwei Liu wrote: > On Tue, Oct 2, 2018 at 5:43 AM Michael S. Tsirkin 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