From owner-freebsd-net  Thu Oct 25 14: 8:36 2001
Delivered-To: freebsd-net@freebsd.org
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
	by hub.freebsd.org (Postfix) with ESMTP id 551D937B401
	for <net@freebsd.org>; Thu, 25 Oct 2001 14:08:32 -0700 (PDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id 919D74CE63; Thu, 25 Oct 2001 17:08:31 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA03918;
	Thu, 25 Oct 2001 17:08:30 -0400 (EDT)
From: Bill Fenner <fenner@research.att.com>
Received: (from fenner@localhost)
	by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA26017;
	Thu, 25 Oct 2001 14:08:30 -0700 (PDT)
Message-Id: <200110252108.OAA26017@windsor.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: rizzo@aciri.org
Subject: Re: performance issues with M_PREPEND on clusters
Cc: wollman@khavrinen.lcs.mit.edu, net@freebsd.org
References:  <20011023110307.A34494@iguana.aciri.org> <200110231917.f9NJH4T32996@khavrinen.lcs.mit.edu> <20011023140318.A35869@iguana.aciri.org>
Date: Thu, 25 Oct 2001 14:08:30 -0700
Versions: dmail (solaris) 2.2j/makemail 2.9b
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org


Luigi Rizzo <rizzo@aciri.org> said:
>On Tue, Oct 23, 2001 at 03:17:04PM -0400, Garrett Wollman wrote:
>> ... the whole purpose of m_pullup is to
>> *guarantee* that the data in question will never be shared.
>
>Technically, it is correct that m_pullup guarantees that the data
>in question will never be shared, but it seems to me more an artifact
>of its implementation than a real goal.

It was not a design goal (in fact, the 4.4 daemon book actually claims
"If the dtom() macro is eventually removed, m_pullup() will no longer
be forced to move data from mbuf clusters."  However, the "ensure that
the data is not shared" side effect is heavily in at least the multicast
code; the bridge code seem to also rely on it.  I wouldn't be surprised
if there were more.

  Bill

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