Date: Wed, 05 Sep 2007 22:51:50 +0100 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Jack Vogel <jfvogel@gmail.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Scott Long <scottl@freebsd.org>, Andre Oppermann <andre@freebsd.org>, Kip Macy <kmacy@FreeBSD.org>, John Baldwin <jhb@yahoo-inc.com> Subject: Re: Thoughts on vlan filter Message-ID: <46DF24F6.1060602@FreeBSD.org> In-Reply-To: <2a41acea0709051352n583b4724o359faaf29a1479d8@mail.gmail.com> References: <2a41acea0709051352n583b4724o359faaf29a1479d8@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jack Vogel wrote: > I had an idea, I was debugging a problem on my new 10G driver a week back, > and found I had the hardware vlan filter enabled by accident, this led me to > wonder about supporting this hardware feature in the driver... > > I have done some experimentation, and find that when the vlan device is > configured, ultimately the SETMULTI ioctl will happen in my driver, this > means I could add code that checks the trunk, finds there is a vlan and > then sets the tag into the filter. > > Any interest, or thoughts ya or nay about my doing this? > I can't say for sure what the right answer here is. It seems reasonable to have a means of checking if the setmulti is happening from a stacked vlan(4) instance. I think it is reasonable to only support this for 2 layers of nesting levels i.e. Q-in-Q, in the mainline stack, and encourage folks to use Netgraph if they need arbitrary nesting levels. Kip raised some performance related concerns about the driver lock being taken whenever multicast address list changes happen, thus deferring or delaying packet flows on other transmit queues, perhaps he can chime in? regards, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46DF24F6.1060602>