Re: Running into an mbuf leak with bridging and tap

From: Maksim Yevmenkin (maksim.yevmenkin_at_savvis.net)
Date: 11/23/04

  • Next message: Martin Eugen: "Re: resolving routes externally" 
    Date: Tue, 23 Nov 2004 08:20:54 -0800
To: Robert Watson <rwatson@freebsd.org>

    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

    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: Martin Eugen: "Re: resolving routes externally"

    Relevant Pages