From owner-freebsd-current@FreeBSD.ORG Sat Apr 17 10:20:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA18016A4E3 for ; Sat, 17 Apr 2004 10:20:37 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 150FB43D2D for ; Sat, 17 Apr 2004 10:20:37 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i3HHKYCa008848; Sat, 17 Apr 2004 13:20:34 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i3HHKYlr008845; Sat, 17 Apr 2004 13:20:34 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 17 Apr 2004 13:20:34 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Andrew Thompson In-Reply-To: <20040417035758.GA66806@kate.fud.org.nz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: RFC: ported NetBSD if_bridge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2004 17:20:38 -0000 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