[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1233027482.7148.42.camel@2710p.home>
Date: Mon, 26 Jan 2009 20:38:02 -0700
From: Alex Williamson <alex.williamson@...com>
To: Rusty Russell <rusty@...tcorp.com.au>
Cc: netdev@...r.kernel.org, markmc@...hat.com, kvm@...r.kernel.org
Subject: Re: [PATCH 4/5] virtio_net: Add a MAC filter table
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists