Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Apr 2004 13:20:34 -0400 (EDT)
From:      Robert Watson <rwatson@freebsd.org>
To:        Andrew Thompson <andy@fud.org.nz>
Cc:        current@freebsd.org
Subject:   Re: RFC: ported NetBSD if_bridge
Message-ID:  <Pine.NEB.3.96L.1040417131529.8431B-100000@fledge.watson.org>
In-Reply-To: <20040417035758.GA66806@kate.fud.org.nz>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sat, 17 Apr 2004, Andrew Thompson wrote:

> The benefits over the current bridge are:
>  * ability to manage the bridge table
>  * spanning tree support

Ah, wonderful.  I've been hoping someone would do an 802.1D implementation
on FreeBSD for years.  I started on one in 1999, but never really made
headway because of other obligations.  I have a copy of 802.1D sitting on
my bookshelf at work to this day :-).

>  * the snazzy brconfig utility
>  * clonable pseudo-interface (is that a benefit?)

Yes.  One of the missing things in src/sys/net/bridge is the ability to
use BPF to view all packets visible on the bridge, rather than packets
that make it onto any particular component interface.  I did add this to
our bridge at one point locally, while working on spanning tree, but never
merged it.  It also means you could assign an additional MAC address,
presumably, to the bridge interface to make things like ARP, etc, work
better with bridges.

> I need a bit of help on the following:
>  * testing
>  * the header includes, I have made a mess of them :)
>  * locking?

I'm happy to take a look at the changes.

>  * updating the brconfig man page
>  * some way to support the sysctl net.link.ether.bridge.config (?)

I think it would make sense to sit down and do a side-by-side comparison
of the two.  If we want to replace the existing net/bridge.c code, I think
we should make sure the new code is of comparable or better performance
(and if not, explore how to adopt performance benefiting approaches in the
current code), and that we can offer configuration compatibility so as not
to shoot the feet too gratuitously of people using the current code.

If there are substantial differences that aren't easy to take care of,
having both implementations simultaneously present is possible, although
possibly also gratuitous.  I think there's a decent argument that
if_bridge and ng_bridge can or should coexist, recognizing that there are
benefits to the arbitrary plugability of the netgraph approach, and that
ng_bridge might be able to take advantage of code features in if_bridge
and share code.  I'm not sure there's an argument for both if_bridge and
regular bridge if if_bridge provides a superset.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Senior Research Scientist, McAfee Research



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040417131529.8431B-100000>