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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
