From owner-freebsd-net@FreeBSD.ORG Tue Apr 7 05:09:39 2009 Return-Path: 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 ; 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: References: Date: Tue, 7 Apr 2009 13:09:37 +0800 Message-ID: From: Sepherosa Ziehau To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Ivan Voras 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 05:09:39 -0000 On Mon, Apr 6, 2009 at 7:59 PM, Robert Watson 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