Re: [Qemu-devel] [PATCH 0/7] virtio-net: Filter cleanup/improvements

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

Hi Mark,

On Tue, 2009-06-09 at 19:25 +0000, Mark McLoughlin wrote:
> On Fri, 2009-06-05 at 14:46 -0600, Alex Williamson wrote:
> 
> > This series cleans up a few things around packet filtering.  I've probably
> > gone a little overboard on breaking up patches, if we want to avoid bumping
> > the save version_id so much, these could be mostly lumped together.  The
> > main features here are more efficient handling of the filtering between
> > unicast and multicast, better overflow tracking, adding more RX modes,
> > and increasing the size of the filter table and control queue depth.
> > 
> > I took the reserved version_id 7 for vnet header support into consideration
> > on the first patch.  I think we should be able to safely add the guts later
> > with the placeholder.  If there are other RX mode controls we should add,
> > let me know, now would be a good time to round out any other flags we can
> > think of. 
> 
> The whole series looks good to me. Please make sure to send Rusty a
> patch with the VIRTIO_NET_F_CTRL_RX_EXTRA etc. header additions.
> 
> The savevm version_id 9 bump is a little gratuitous, but I don't think
> it's a big deal - I'd prefer to see cleanly separated patches like this,
> and it wouldn't have been easy to e.g. split out the savevm changes into
> a patch of their own at the end.
> 
> The vnet header version_id reservation is a good idea.

Thanks for the comments.  Do you mean the version 8 jump is gratuitous
(make the promisc/allmulti fields smaller)?  It is, but it was annoying
me, especially since I didn't want to waste even more space with these
new options.  Version 9 adds the overflow fields, which I think is
necessary or else we run into problems if a guest only reprograms the
MAC filter table w/o first setting those RX mode fields.  Then we don't
have the info to remember if the guest requested promisc or we enabled
it ourselves.

> I've given this stuff some light testing, but would you care to outline
> some instructions for some basic tests for as much as possible of this
> stuff using a Linux guest? i.e. broadcast, multicast, promisc, mac
> table, vlan table etc. - that's quite a set of tests you need to cover
> all those cases.

Sure, some of the new features can't be tested in Linux, so I'm relying
on some test reports from DMX to prove that it works.  I typically test
promiscuous and all multi using the ifconfig flags to enable them,
tcpdump is also a good test for promisc.  You'll need to add some
instrumentation to the filter function to know when packets are getting
dropped in qemu and the absence of dropped packets means they're getting
through.  For the MAC filter table, I use macvlans:

ip link add link eth0 eth$i type macvlan
dhclient eth$i

Add some instrumentation to the MAC table, watch it fill up.  Eventually
you'll run out of entries (it helps to reduce the table size for
testing), at which point we should set the multi overflow and continue
filling unicast (multicast MACs stop getting dropped).  Those will fill
up, and we'll enable uni overflow.  Actually getting traffic to each MAC
is a little more difficult.  You need to use arp -s to insert an ARP
cache entry for the macvlan to make sure the traffic isn't filtered.

VLANs I typically test by, again, watching what gets dropped.  For
instance, setup a remote system on a VLAN, ping the broadcast, see that
packets from that MAC are dropped.  Enable the VLAN on the guest using
vconfig and see that packets are no longer dropped, and there's
connectivity on the VLAN.

AFAIK, Linux doesn't have any obvious way to test alluni, nouni, nomulti
or the broadcast switches.  The logic for these is pretty simple though
and some of them track aspects of the MAC filter table overflow.
Thanks,

Alex