Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 Apr 2002 09:28:30 -0500 (EST)
From:      Andrew Gallatin <gallatin@cs.duke.edu>
To:        bmah@FreeBSD.ORG
Cc:        hackers@FreeBSD.ORG
Subject:   Re: Fatal trap 12: page fault while in kernel mode 
Message-ID:  <15533.46222.49598.958821@grasshopper.cs.duke.edu>
In-Reply-To: <200204050504.g355493C001200@intruder.bmah.org>
References:  <20020403181854.I42720-100000@angui.sh> <15532.29114.310072.957330@grasshopper.cs.duke.edu> <200204050504.g355493C001200@intruder.bmah.org>

next in thread | previous in thread | raw e-mail | index | archive | help

Bruce A. Mah writes:
 > 
 > I was discussing this with some of my cow-orkers, as we've had a similar
 > situation (cluster mbufs getting temporarily depleted on a
 > 4.5-RELEASE-p2 NFS server with Linux and FreeBSD clients, but no kernel
 > panics).  Shouldn't the net.inet.ip.maxfragpackets sysctl variable
 > (introduced in 4.4-RELEASE) limit the number of fragments on the
 > reassembly queue(s)?  This value looks to be about 1/4 the number of
 > cluster mbufs, by default.

That's a good point.  When I was bitten by this, I didn't have time to
mess with things & I cranked down the read/write size on the linux
clients.   

The problem is that ip_maxfragpackets is:
"Maximum number of IPv4 fragment reassembly queue entries"


You (& I, & most people probably) took that number to mean the cap on
the number of mbufs sitting on reassembly queues.  However, its really
a cap on the number of fragmented packets sitting on reassembly
queues:

        /*
         * If first fragment to arrive, create a reassembly queue.
         */
        if (fp == 0) {
                /*
                 * Enforce upper bound on number of fragmented packets
                 * for which we attempt reassembly;
                 * If maxfrag is 0, never accept fragments.
                 * If maxfrag is -1, accept all fragments without limitation.
		 <...>

Since the linux host is sending 16K packets, that means that each
packet is made up of 11 cluster mbufs (assuming a 1500 byte mtu).
There can be as many as 10 cluster mbufs on the reassembly queue for
for each packet.

Lets say we have 2048 cluster mbufs.  That makes maxfragpackets 512.
However, 512 * 10 mbufs = 5120 mbufs.  Oops.

I think the limit should probably be something much smaller, like
maybe nmbclusters / (net.inet.udp.recvspace / 1472).  Or the
implementation & name should be changed to "maxfragmbufs"

Drew


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15533.46222.49598.958821>