From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: virtio-dev-return-5070-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 7BF61985D0B for ; Wed, 28 Nov 2018 20:43:31 +0000 (UTC) Date: Wed, 28 Nov 2018 15:43:23 -0500 From: "Michael S. Tsirkin" Message-ID: <20181128154244-mutt-send-email-mst@kernel.org> References: <20181122132626-mutt-send-email-mst@kernel.org> <25a340eb-62a8-ea90-5f0d-0ee3171479ce@intel.com> <20181128120516-mutt-send-email-mst@kernel.org> <20181128123424-mutt-send-email-mst@kernel.org> <0a81c110-610e-2183-3483-95faf53c3fce@intel.com> <20181128135154-mutt-send-email-mst@kernel.org> <1aeab969-f47f-42c3-31a0-b4c5df647d58@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1aeab969-f47f-42c3-31a0-b4c5df647d58@oracle.com> Subject: Re: [virtio-dev] [PATCH v4] content: Introduce VIRTIO_NET_F_STANDBY feature To: si-wei liu Cc: "Samudrala, Sridhar" , Carolyn , Sameeh Jubran , Siwei Liu , venu.busireddy@oracle.com, cohuck@redhat.com, virtio-dev , liran.alon@oracle.com, Yan Vugenfirer , "Brandeburg, Jesse" List-ID: On Wed, Nov 28, 2018 at 12:28:42PM -0800, si-wei liu wrote: > > > On 11/28/2018 12:06 PM, Michael S. Tsirkin wrote: > > On Wed, Nov 28, 2018 at 10:39:55AM -0800, Samudrala, Sridhar wrote: > > > On 11/28/2018 9:35 AM, Michael S. Tsirkin wrote: > > > > On Wed, Nov 28, 2018 at 09:31:32AM -0800, Samudrala, Sridhar wrote: > > > > > On 11/28/2018 9:08 AM, Michael S. Tsirkin wrote: > > > > > > On Mon, Nov 26, 2018 at 12:22:56PM -0800, Samudrala, Sridhar wrote: > > > > > > > > Update: > > > > > > > > I have just set the vf mac's address to 0 (ip link set ens2f0 vf 1 mac > > > > > > > > 00:00:00:00:00:00) after unplugging it (the primary device) and the > > > > > > > > pings started working again on the failover interface. So it seems > > > > > > > > like the frames were arriving to the vf on the host. > > > > > > > > > > > > > > > > > > > > > > > Yes. When the VF is unplugged, you need to reset the VFs MAC so that the packets > > > > > > > with VMs MAC start flowing via VF, bridge and the virtio interface. > > > > > > > > > > > > > > Have you looked at this documentation that shows a sample script to initiate live > > > > > > > migration? > > > > > > > https://www.kernel.org/doc/html/latest/networking/net_failover.html > > > > > > > > > > > > > > -Sridhar > > > > > > Interesting I didn't notice it does this. So in fact > > > > > > just defining VF mac will immediately divert packets > > > > > > to the VF? Given guest driver did not initialize VF > > > > > > yet won't a bunch of packets be dropped? > > > > > There is typo in my stmt above (VF->PF) > > > > > When the VF is unplugged, you need to reset the VFs MAC so that the packets > > > > > with VMs MAC start flowing via PF, bridge and the virtio interface. > > > > > > > > > > When the VF is plugged in, ideally the MAC filter for the VF should be added to > > > > > the HW once the guest driver comes up and can receive packets. Currently with intel > > > > > drivers, the filter gets added to HW as soon as the host admin sets the VFs MAC via > > > > > ndo_set_vf_mac() api. So potentially there could be packet drops until the VF driver > > > > > comes up in the VM. > > > > > > > > > > > > > > Can this be fixed in the intel drivers? > > > I just checked and it looks like this seems to have been addressed in the > > > ice 100Gb driver. Will bring this up issue internally to see if we can change this > > > behavior in i40e/ixgbe drivers. > > Also what happens if the mac is programmed both in PF (e.g. with > > macvtap) and VF? Ideally VF will take precedence. > I'm seriously doubtful that legacy Intel NIC hardware can do that instead of > mucking around with software workaround in the PF driver. Actually, the same > applies to other NIC vendors when hardware sees duplicate filters. There's > no such control of precedence on one over the other. > > > -Siwei > > > OK I guess we will need another feature bit for a software workaround then. -- MST --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org