[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111125092828.706a2929@nehalam.linuxnetplumber.net>
Date: Fri, 25 Nov 2011 09:28:28 -0800
From: Stephen Hemminger <shemminger@...tta.com>
To: jhs@...atatu.com
Cc: hadi@...erus.ca, Jesse Gross <jesse@...ira.com>,
netdev <netdev@...r.kernel.org>, dev@...nvswitch.org,
David Miller <davem@...emloft.net>,
Chris Wright <chrisw@...hat.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Eric Dumazet <eric.dumazet@...il.com>,
John Fastabend <john.r.fastabend@...el.com>,
Justin Pettit <jpettit@...ira.com>
Subject: Re: Open vSwitch Design
On Fri, 25 Nov 2011 06:24:36 -0500
jamal <hadi@...erus.ca> 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.
--
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