Re: [PATCH 4/5] virtio_net: Add a MAC filter table

Rusty Russell
2009-01-28T10:45:13Z

On Tuesday 27 January 2009 14:08:02 Alex Williamson wrote:
> Hi Rusty,
>
> On Tue, 2009-01-27 at 13:00 +1030, Rusty Russell wrote:
> > On Saturday 17 January 2009 07:43:34 Alex Williamson wrote:
> > > As with most real hardware, unicast addresses have priority in
> >
> > > the filter table so we can avoid enabling full promiscuous
> >
> > > until both unicast and multicast address overflow.
> >
> > Why not pretend to have infinite, and have the host turn promisc on
> > when *it*
> >
> > decides? Skip the alloc call, and just use a feature bit like
> > everything else?
>
> I suppose it's just a matter of where do you want to add the smarts and
> the tune-ability. Since we can't actually have an infinite table and an
> array implementation seems to make sense from an efficiency standpoint,
> it needs to be defined by someone to be a fixed size before we start
> using it. I was hoping the guest driver might have a better idea how it
> plans to use the filter table and that there'd be some benefit to having
> that handshake happen between the driver and the backend. The module
> parameter fell out of this and seems rather convenient.
>
> I could pursue this is you like, but I'm not sure of the benefit,
> particularly if we want to give the user some control of the size of the
> actual table. Thoughts? Thanks for the comments,

I don't think the either-or case is real. Say the user decides they want a table of 1000000 entries. And the backend says "no way, I have a 16 array"? Currently you get nothing.

I guess your qemu code does dynamic allocation. But I'm sure you put a limit in there, right? :)

We don't want some complex negotiation, and I don't think the guest has any more clue than the host, nor can do much about it.

Cheers,
Rusty.