From owner-freebsd-net@FreeBSD.ORG  Tue Apr  7 20:12:04 2009
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id F0E48106566B
	for <net@freebsd.org>; Tue,  7 Apr 2009 20:12:04 +0000 (UTC)
	(envelope-from wollman@hergotha.csail.mit.edu)
Received: from hergotha.csail.mit.edu (hergotha.csail.mit.edu [66.92.79.170])
	by mx1.freebsd.org (Postfix) with ESMTP id A13A38FC14
	for <net@freebsd.org>; Tue,  7 Apr 2009 20:12:04 +0000 (UTC)
	(envelope-from wollman@hergotha.csail.mit.edu)
Received: from hergotha.csail.mit.edu (localhost [127.0.0.1])
	by hergotha.csail.mit.edu (8.14.2/8.14.2) with ESMTP id n37KC3Wb050335; 
	Tue, 7 Apr 2009 16:12:03 -0400 (EDT)
	(envelope-from wollman@hergotha.csail.mit.edu)
Received: (from wollman@localhost)
	by hergotha.csail.mit.edu (8.14.2/8.13.8/Submit) id n37KC3lA050334;
	Tue, 7 Apr 2009 16:12:03 -0400 (EDT) (envelope-from wollman)
Date: Tue, 7 Apr 2009 16:12:03 -0400 (EDT)
From: Garrett Wollman <wollman@hergotha.csail.mit.edu>
Message-Id: <200904072012.n37KC3lA050334@hergotha.csail.mit.edu>
To: rwatson@freebsd.org
X-Newsgroups: mit.lcs.mail.freebsd-net
In-Reply-To: <alpine.BSF.2.00.0904061238250.34905@fledge.watson.org>
References: <gra7mq$ei8$1@ger.gmane.org>
	<alpine.BSF.2.00.0904051422280.12639@fledge.watson.org>
	<grac1s$p56$1@ger.gmane.org>
	<alpine.BSF.2.00.0904051440460.12639@fledge.watson.org>
	<grappq$tsg$1@ger.gmane.org>
	<alpine.BSF.2.00.0904052243250.34905@fledge.watson.org>
	<grbcfg$poe$1@ger.gmane.org>
Organization: None
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0
	(hergotha.csail.mit.edu [127.0.0.1]);
	Tue, 07 Apr 2009 16:12:03 -0400 (EDT)
X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED
	autolearn=disabled version=3.2.5
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
	hergotha.csail.mit.edu
Cc: net@freebsd.org
Subject: Re: Advice on a multithreaded netisr  patch?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Apr 2009 20:12:05 -0000

In article <alpine.BSF.2.00.0904061238250.34905@fledge.watson.org>,
Robert Watson writes:

>m_pullup() has to do with mbuf chain memory contiguity during packet 
>processing.

Historically, m_pullup() also had one other extremely important
function: to make sure that the header data you were about to modify
was not stored in a (possibly shared) cluster.  Thus, in the input
path for a typical driver which puts the whole packet into a cluster,
the very first m_pullup() would allocate a new plain mbuf, carefully
align the data pointer to allow for both prepending more headers and
pulling more header data out, and copy the requested data into the
internal buffer of the mbuf.

-GAWollman