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

[si-wei liu <si-wei.liu@oracle.com>]

On 11/28/2018 12:43 PM, Michael S. Tsirkin wrote:
> 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.
OK but then what if the NIC vendor is not willing to take a software 
workaround for this feature?

-Siwei