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, Alex -- Alex Williamson HP Open Source & Linux Org. -- 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
