From owner-freebsd-net@FreeBSD.ORG  Tue Apr  7 05:09:39 2009
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 10907106570E;
	Tue,  7 Apr 2009 05:09:38 +0000 (UTC)
	(envelope-from sepherosa@gmail.com)
Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29])
	by mx1.freebsd.org (Postfix) with ESMTP id 7B10B8FC14;
	Tue,  7 Apr 2009 05:09:38 +0000 (UTC)
	(envelope-from sepherosa@gmail.com)
Received: by yx-out-2324.google.com with SMTP id 8so1575935yxm.13
	for <multiple recipients>; Mon, 06 Apr 2009 22:09:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:mime-version:received:in-reply-to:references
	:date:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	bh=A4kqYJ2JkKb+2Pq4o4vVzOREP9MtdzibFkqGr/2JBlA=;
	b=dHX3oWVMhi1s1z3OKd0KRNMY3fQij8ku6ARPsupmc/ym0OEHWJS4NPoVNExLz9QxJm
	nGEI1Yv+feIXmW21nR7H1lZ56wpKQdM/ETdmg1USxg83NIJGEWEq/IF6zZvmf5DFMpj6
	0m6mHAEhO/SJ61S+3VPdEIlN1vH9qIjjJ7glA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	b=SIKzhFZ0O8zD2VASu3xmmy4VFUvACCjkUIpK4IW0zmoVTsV1Jf6IsIJN72pRP9hWaF
	IGnXzo0h3T9nj4r9Cn7lzSM2KQIPbJvkICHFJneE5xPsWHZIFrafflivFpSPHyAFzYQQ
	xUuQS3n/rNS50qJssn5cIR6h7R52Ne6+qe9f4=
MIME-Version: 1.0
Received: by 10.151.103.11 with SMTP id f11mr9723503ybm.235.1239080977933; 
	Mon, 06 Apr 2009 22:09:37 -0700 (PDT)
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>
	<alpine.BSF.2.00.0904061238250.34905@fledge.watson.org>
Date: Tue, 7 Apr 2009 13:09:37 +0800
Message-ID: <ea7b9c170904062209tda44636tb9a18755ec0c5bb3@mail.gmail.com>
From: Sepherosa Ziehau <sepherosa@gmail.com>
To: Robert Watson <rwatson@freebsd.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: freebsd-net@freebsd.org, Ivan Voras <ivoras@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 05:09:39 -0000

On Mon, Apr 6, 2009 at 7:59 PM, Robert Watson <rwatson@freebsd.org> wrote:
>
> m_pullup() has to do with mbuf chain memory contiguity during packet
> processing.  The usual usage is something along the following lines:
>
>        struct whatever *w;
>
>        m = m_pullup(m, sizeof(*w));
>        if (m == NULL)
>                return;
>        w = mtod(m, struct whatever *);
>
> m_pullup() here ensures that the first sizeof(*w) bytes of mbuf data are
> contiguously stored so that the cast of w to m's data will point at a
> complete structure we can use to interpret packet data.  In the common case
> in the receipt path, m_pullup() should be a no-op, since almost all drivers
> receive data in a single cluster.
>
> However, there are cases where it might not happen, such as loopback traffic
> where unusual encapsulation is used, leading to a call to M_PREPEND() that
> inserts a new mbuf on the front of the chain, which is later m_defrag()'d
> leading to a higher level header crossing a boundary or the like.
>
> This issue is almost entirely independent from things like the cache line
> miss issue, unless you hit the uncommon case of having to do work in
> m_pullup(), in which case life sucks.
>
> It would be useful to use DTrace to profile a number of the workfull m_foo()
> functions to make sure we're not hitting them in normal workloads, btw.

I highly suspect m_pullup will take any real effect on RX path, given
how most of drivers allocate the mbuf for RX ring (all RX mbufs should
be mclusters).

Best Regards,
sephe

-- 
Live Free or Die