OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[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 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]