From owner-freebsd-net  Mon Jul 10 12:44: 4 2000
Delivered-To: freebsd-net@freebsd.org
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2392637BD4C; Mon, 10 Jul 2000 12:43:57 -0700 (PDT)
	(envelope-from ken@panzer.kdm.org)
Received: (from ken@localhost)
	by panzer.kdm.org (8.9.3/8.9.1) id NAA26975;
	Mon, 10 Jul 2000 13:43:47 -0600 (MDT)
	(envelope-from ken)
Date: Mon, 10 Jul 2000 13:43:47 -0600
From: "Kenneth D. Merry" <ken@kdm.org>
To: Alfred Perlstein <bright@wintelcom.net>
Cc: David Greenman <dg@root.com>, net@freebsd.org, dg@freebsd.org,
	wollman@freebsd.org
Subject: Re: argh! Re: weird things with M_EXT and large packets
Message-ID: <20000710134346.A26914@panzer.kdm.org>
References: <20000709205124.A25571@fw.wintelcom.net> <200007100553.WAA01544@implode.root.com> <20000710000237.C25571@fw.wintelcom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <20000710000237.C25571@fw.wintelcom.net>; from bright@wintelcom.net on Mon, Jul 10, 2000 at 12:02:37AM -0700
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Mon, Jul 10, 2000 at 00:02:37 -0700, Alfred Perlstein wrote:
> Actually, it does happen, you still need to vtophys once per
> mbuf/cluster, allowing someone to present super large clusters
> reduces allocation in the mbuf systems and cache utilization.
> 
> The detection of this situation is simply:
> 
> if ((mh_flags & M_EXT) != 0 && m->m_ext.ext_free != NULL
> 	&& (m_data % PAGE_SIZE) + m_len > PAGE_SIZE) {
> 	/* split */
> }
> 
> The mod operation acting on a power of two should reduce to a
> bitmask, so the overhead of doing this isn't that great.
> 
> The test could probably dispense with the EXT and ext_free checks
> and wind up faster than with them in.

Another way to do it would be to have a flag that tells the driver that it
should check for fragmentation.  You'll just need to make sure that the
flag gets copied in the right places in the mbuf code when mbufs are
copied, etc.  (An easy way to check that out is to see what the mbuf code
does with M_EXT.)

> Mike Smith pointed me at some macros/functions that NetBSD uses to
> accomplish this, I'll be investigating them as I'd rather make a
> single allocation than one per 4k page.

Yeah, if we're going to do this, we'll want a common set of routines to
traverse the memory and pull out the various chunks.

Ken
-- 
Kenneth Merry
ken@kdm.org


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