Re: [Qemu-devel] [PATCH][RFC] qemu:virtio-net: Use TUNSETTXFILTER for MAC filtering

[Alex Williamson]

Hi Paul,

On Fri, 2009-02-06 at 15:12 +0000, Paul Brook wrote:
> On Friday 06 February 2009, Alex Williamson wrote:
> > Now that virtio-net knows what packets the guest wants to see, we
> > can start moving the filtering down the stack.  This patch adds
> > an interface to set the software filter in the tap device.  It's
> > fairly limited, but we can back it up with our own filtering if it
> > overflows.
> 
> I think you've got the abstraction wrong here. Devices certainly shouldn't 
> care what else is connected to the vlan.
> 
> Remember that a qemu vlan is an arbitrary set of network devices. You need to 
> be able to support multiple devices all with their own filters.

In the model I'm considering, and I need to change the code to enforce
this, there are two devices on the vlan.  One side is the backend of a
NIC that's exported to the guest.  The other side is a tap or socket or
whatever transports packets into and out of our userspace instance.  If
there are more devices, the vlan needs to be treated as a shared media
with filtering left to the emulated NIC.

> There should be two interface points between the the vlan and the device:
> 1) The device can indicate that it only cares about incoming (vlan to device) 
> packets sent to a subset of MAC addresses.
> 2) The vlan can request that a device discards outgoing (device to vlan) 
> packets that don't match a subset of MAC addresses.
> 
> Typically a emulated NIC will implement (1) and a host interface will 
> implement (2).
> 
> The generic vlan code should be responsible for using the information 
> provided 
> by (1) to set (2) appropriately. Remember that network devices can be 
> hotplugged.

Do you think it's worthwhile for the vlan to save and consolidate
filtering from multiple (1) sources to program (2)?  My interface is
effectively short circuiting and letting the (1) agent set (2).  As you
mention below, this is an optimization, so I think it's reasonable that
if we exceed a 1x1 configuration of (1)s and (2)s, we need to reset back
to a shared media model and do filtering in the (1) agent, which is how
I think we should handle hotplug.

> On a related note, you need to add comments making it clear that this is a 
> performance optimisation, and must not be relied on. A device may still 
> receive packets that should have been filtered out. If a device needs 
> reliable filtering (most "real" hardware does), then this still needs to be 
> implemented per-device.

Yes, I'll add something.  Thanks for the comments,

Alex