Re: [PATCH 2/2][RFC] virtio_net: Add MAC fitler table support

From: Anthony Liguori <anthony@codemonkey.ws>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Alex Williamson <alex.williamson@hp.com>,
	kvm <kvm@vger.kernel.org>, netdev <netdev@vger.kernel.org>,
	Mark McLoughlin <markmc@redhat.com>
Subject: Re: [PATCH 2/2][RFC] virtio_net: Add MAC fitler table support
Date: Sat, 10 Jan 2009 12:18:17 -0600	[thread overview]
Message-ID: <4968E669.8040707@codemonkey.ws> (raw)
In-Reply-To: <200901102148.54962.rusty@rustcorp.com.au>

Rusty Russell wrote:
> On Thursday 08 January 2009 04:36:03 Alex Williamson wrote:
>   
>> virtio_net: Add MAC fitler table support
>>     
>
> Ah, I see.  You really want multiple mac addresses, not just multicast
> filtering?
>
> Anthony, you think a control channel?  We can add a virtqueue, but it seems like a lot of work...
>   

I think it's the only way to solve the problem in a virtio friendly way.

Another option would be extending the config space by a very large 
size.  We would have to make some changes to virtio-pci to switch to 
MMIO but that's easy enough.  From a high level perspective, I don't 
like the idea of having the config space be extremely large and used as 
a communication mechanism between guests.  It really should be for 
device configuration data that's relatively static.  I think we abuse 
the config space in the virtio-balloon driver.

Ideally, you'd have an area of guest memory sized by the guest (so there 
was no intrinsic limit on table size) that was given to the host to use 
as the filter tables.  The only way this works with virtio is if you 
send this over a virtqueue in the form of messages.  You could write a 
pfn to the config space but then you lose all the mapping/unmapping 
abstraction that virtqueue gives you (even though we don't do anything 
useful with that abstraction today :-)).

So yeah, I think a control queue is the way to go.

Regards,

Anthony Liguori

> Rusty.
>   