From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: Open vSwitch Design Date: Fri, 25 Nov 2011 09:28:28 -0800 Message-ID: <20111125092828.706a2929@nehalam.linuxnetplumber.net> References: <1322173833.1944.5.camel@mojatatu> <20111124212021.2ae2fb7f@s6510.linuxnetplumber.net> <1322220276.1908.75.camel@mojatatu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Chris Wright , Herbert Xu , Eric Dumazet , netdev , hadi-fAAogVwAN2Kw5LPnMra/2Q@public.gmane.org, Fastabend , John-/PVsmBQoxgPKo9QCiBeYKEEOCMrvLtNR@public.gmane.org, David Miller To: jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org Return-path: In-Reply-To: <1322220276.1908.75.camel@mojatatu> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dev-bounces-yBygre7rU0TnMu66kgdUjQ@public.gmane.org Errors-To: dev-bounces-yBygre7rU0TnMu66kgdUjQ@public.gmane.org List-Id: netdev.vger.kernel.org On Fri, 25 Nov 2011 06:24:36 -0500 jamal wrote: > Most hardware bridges out there support all different modes: > You can have learning in the hardware or defer it to user/control plane > by setting some flags. You can have broadcasting done in hardware or > defer to user space. > The mods i was thinking of is to bring the Linux bridge to have the > same behavior. You then need to allow netlink updates of bridge MAC > table from user space. There may be weaknesses with the current bridging > code in relation to Vlans that may need to be addressed. > > [But my concern was not so much the bridge - because changes are needed > in that case; it is the "match, actionlist" that is already in place > that got to me.] The bridge module is already overly complex. Rather than adding more modes, it should be split into separate modules. If you look at macvlan, you will see it is already a subset of to bridge. Another example of this is the team driver which is really just a subset of the bonding code.