From owner-freebsd-net@FreeBSD.ORG Tue Nov 23 16:20:50 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB15316A4CE; Tue, 23 Nov 2004 16:20:50 +0000 (GMT) Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FD4943D49; Tue, 23 Nov 2004 16:20:50 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [192.168.1.254] (really [24.52.242.150]) by mta9.adelphia.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20041123162049.JUVB14438.mta9.adelphia.net@[192.168.1.254]>; Tue, 23 Nov 2004 11:20:49 -0500 Message-ID: <41A36366.2000202@savvis.net> Date: Tue, 23 Nov 2004 08:20:54 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: Running into an mbuf leak with bridging and tap X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 16:20:50 -0000 Robert, > I'm running an ethernet over TCP bridge using a combination of the native > ethernet bridge support and the tap driver. Basically, a daemon sits on > /dev/tapX and bridges ethernet frames using a small header over a TCP > connection. The bridge support is loaded as a kld, as is the tap support, > and both modules remain resident from then on. After a couple of days, > perhaps triggered by the connection going up and down and leaving bridging > turned on even when nothing is listening on the tap device, the endpoints > will run out of mbufs: > > 26707 mbufs in use > 25453/25600 mbuf clusters in use (current/max) > 0/3/6656 sfbufs in use (current/peak/max) > 57582 KBytes allocated to network > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > Under normal circumstances (i.e., without tap and ethernet bridging on), > this doesn't happen, suggesting that maybe there's a leak in the bridging > code or tap code. I've now seen this with three boxes, a blend of UP and > SMP. I haven't yet had a chance to sit down with a debugging kernel. Has > anyone else seen anything like this? could you please try to use ng_bridge(4)? example scripts are in /usr/share/examples/netgraph. this could tell me if tap(4) is at fault. max