From owner-freebsd-arch@FreeBSD.ORG Wed Aug 20 09:34:45 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 785AC16A4BF; Wed, 20 Aug 2003 09:34:45 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC96A43F85; Wed, 20 Aug 2003 09:34:44 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange.errno.com (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h7KGYe7N026721 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 20 Aug 2003 09:34:43 -0700 (PDT) (envelope-from sam@errno.com) Date: Wed, 20 Aug 2003 09:34:54 -0700 From: Sam Leffler To: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Message-ID: <510776858.1061372094@melange.errno.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: CFR: bridge locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2003 16:34:45 -0000 http://www.freebsd.org/~sam/bridge.patch This patch adds locking and also overhauls the bridge code some to do things like replace explicit numbers with #defines and cleanup the debugging code. I also restructured the forwarding code to avoid grabbing the ifnet lock if possible and optimized the common case of bridging two interfaces. There are a couple of LOR issues to be resolved before it can be committed. In particular the output path has a LOR that can deadlock. I'm making it available for review now in case folks have other comments. Beware that buried in these changes are a renaming of the bridge MIB variables to be under a net.link.ether.bridge. node. Those changes will not be carried over into the committed code unless folks are interested (since it'll break lots of rc scripts). Note that drivers that operate Giant-free with bridging need to release their "driver lock" before passing packets up. Otherwise the up call can result in an immediate return through the start method and deadlock (unless the lock is marked to allow recursion, which should be eliminated if at all possible). I've made these modifications for the em, wi, and sis drivers but have not committed them. The fxp driver already does this and the ath driver has a totally different locking strategy where this doesn't occur. Short term dropping the lock around the up call will work but is suboptimal. Long term we may want to revise the locking strategy for drivers to eliminate this issue. This will likely be revisited when I get to more performance tuning (unless someone else does it--hint hint). One other minor change: I moved the printf "BRIDGE 020214 loaded" under bootverbose. Can anyone tell me what 020214 means? This code has been in "production use" on my interior firewall (a soekris box) for a week. This box runs with the sis driver Giant-free. Sam