Re: [PATCH 0/4] qemu: TAP filtering support

[Alex Williamson <alex.williamson@hp.com>]

Hi Mark,

Thanks for the comments.

On Wed, 2009-02-11 at 19:31 +0000, Mark McLoughlin wrote:
> 
>   - The logic around "is this a NIC+TAP pair?" would be good to have a 
>     better API around. We need this to merge virtio GSO support too. 
>     Anthony had some ideas here.

Ok, I'll see if I can dig that up.

>   - I think you could keep the client_added()/removed() logic in net.c 
>     and things would be a lot cleaner. I think you just want to trigger 
>     a reload of the filter, right? So a "reload this filter" callback 
>     to qemu_vlan_rxfilter() might do it.

In this series, the vlan doesn't maintain state for the filter, so a
reload requires interaction of the NIC backend.  Anthony had requested a
common software filter that would make something like you're suggesting
easier, but I'm still wrestling with the nuances of how that might work.
Things like the e1000 multicast hash throw a kink in the plan, which
left me with each NIC needing to re-enable it's own filtering when
another client is added.

>   - What do we need rxfilter=on|off on the command line for?

Primarily because the current tun driver in Linux has a bug that it can
drop unicast packets requested to be included in the filter if it
overflows the exact match table.

http://www.spinics.net/lists/netdev/msg88451.html

Thanks,

Alex