[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/4] add failover feature for assigned network d
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices |
Date: |
Thu, 6 Jun 2019 17:49:27 -0400 |
On Mon, Jun 03, 2019 at 02:18:19PM -0400, Laine Stump wrote:
> On 6/3/19 2:12 PM, Michael S. Tsirkin wrote:
> > On Mon, Jun 03, 2019 at 02:06:47PM -0400, Laine Stump wrote:
> > > On 5/28/19 10:54 PM, Michael S. Tsirkin wrote:
> > > > On Tue, May 28, 2019 at 05:14:22PM -0700, si-wei liu wrote:
> > > > >
> > > > >
> > > > > On 5/21/2019 11:49 AM, Jens Freimann wrote:
> > > > > > On Tue, May 21, 2019 at 07:37:19AM -0400, Michael S. Tsirkin wrote:
> > > > > > > On Tue, May 21, 2019 at 09:21:57AM +0200, Jens Freimann wrote:
> > > > > > > > On Mon, May 20, 2019 at 04:56:57PM -0600, Alex Williamson wrote:
> > >
> > > > > > > Actually is there a list of devices for which this has been tested
> > > > > > > besides mlx5? I think someone said some old intel cards
> > > > > > > don't support this well, we might need to blacklist these ...
> > > > > >
> > > > > > So far I've tested mlx5 and XL710 which both worked, but I'm
> > > > > > working on testing with more devices. But of course help with
> > > > > > testing
> > > > > > is greatly appreciated.
> > > > >
> > > > > It won't work on Intel ixgbe and Broadcom bnxt_en, which requires
> > > > > toggling
> > > > > the state of tap backing the virtio-net in order to release/reprogram
> > > > > MAC
> > > > > filter. Actually, it's very few NICs that could work with this - even
> > > > > some
> > > > > works by chance the behavior is undefined. Instead of blacklisting it
> > > > > makes
> > > > > more sense to whitelist the NIC that supports it - with some new sysfs
> > > > > attribute claiming the support presumably.
> > > > >
> > > > > -Siwei
> > > >
> > > > I agree for many cards we won't know how they behave until we try. One
> > > > can consider this a bug in Linux that cards don't behave in a consistent
> > > > way. The best thing to do IMHO would be to write a tool that people can
> > > > run to test the behaviour.
> > >
> > > Is the "bad behavior" something due to the hardware of the cards, or their
> > > drivers? If it's the latter, then at least initially having a whitelist
> > > would be counterproductive, since it would make it difficult for relative
> > > outsiders to test and report success/failure of various cards.
> >
> > We can add an "ignore whitelist" flag. Would that address the issue?
>
> It would be better than requiring a kernel/qemu recompile :-)
>
>
> Where would the whilelist live? In qemu or in the kernel? It would be
> problematic to have the whitelist in qemu if kernel driver changes could fix
> a particular card.
So originally I thought:
- add some interface in the kernel to signal new behaviour
- start with a whitelist in qemu
- if not on the whitelist, check the new interface
- if not there, check a "force" flag on the device
But one problem with all of the above is that it's actually
too late. With a broken driver when management sets MAC on the
to-be-primary VF traffic stops being sent to standby.
> Beyond that, what about *always* just issuing some sort of warning rather
> than completely forbidding a card that wasn't whitelisted? (Haven't decided
> if I like that better or not (and it probably doesn't matter, since I'm not
> a "real" user, but I thought I would mention it).
People tend to ignore warnings :)
--
MST