Date: Tue, 23 Nov 2004 08:20:54 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: Robert Watson <rwatson@freebsd.org> Cc: net@freebsd.org Subject: Re: Running into an mbuf leak with bridging and tap Message-ID: <41A36366.2000202@savvis.net> In-Reply-To: <Pine.NEB.3.96L.1041123093708.66539K-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1041123093708.66539K-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41A36366.2000202>