qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/4] qemu:virtio-net: Add support for qemu_vlan_


From: Paul Brook
Subject: Re: [Qemu-devel] [PATCH 3/4] qemu:virtio-net: Add support for qemu_vlan_rxfilter
Date: Thu, 12 Feb 2009 17:05:53 +0000
User-agent: KMail/1.9.9

On Thursday 12 February 2009, Alex Williamson wrote:
> On Thu, 2009-02-12 at 16:26 +0000, Paul Brook wrote:
> > > +static void virtio_net_vlan_client_added(void *opaque)
> > >...
> > > +static void virtio_net_vlan_client_removed(void *opaque)
> >
> > Why are these two different?
> >
> > It looks like what you really want is a callback for "Something changed,
> > and you need to reset your MAC filter."
>
> I think we'd end up with a race if we only had one callback.  For
> instance if "change" was the result of a vlan client being removed, the
> tap would clear the filter and the nic would try to install a filter.
> The results would be different based on the calling order.

In that case either your implementation or your abstraction is wrong. 
Devices shouldn't need to know or care why a filter failed to apply.

I'm not sure what you mean by "the tap would clear the filter".

You have three options:

- Devices request a filter, and that request may fail. qemu notifies the 
device when it needs to retry the filter. It doesn't make any difference 
whether we think we just broke the old filter, or we think a previously 
failed filter may succeed now, the device response is the same: Try to set a 
filter and see if it works. This is what I assume you're trying to implement.
- Implement reliable filters. The device requests a filter once[1]. qemu makes 
sure that filter is always honored.
- Devices request a filter once. qemu remembers what that filter is, and 
notifies the device if/when that filter becomes active/inactive.

Paul

[1] once == every time the filter set changes.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]