From owner-freebsd-net@FreeBSD.ORG Tue Apr 7 09:26:32 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 38F64106568C; Tue, 7 Apr 2009 09:26:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0C6CD8FC08; Tue, 7 Apr 2009 09:26:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id ADFAE46B91; Tue, 7 Apr 2009 05:26:31 -0400 (EDT) Date: Tue, 7 Apr 2009 10:26:31 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <49DAF447.5020407@elischer.org> Message-ID: References: <49DAF447.5020407@elischer.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Sepherosa Ziehau , 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 09:26:32 -0000 On Mon, 6 Apr 2009, Julian Elischer wrote: > while this is true, m_pullup ALWAYS does things so in fact you want to > always put it in a test to see if it is really needed.. Then m_pullup() should be fixed? Keeping the expression of the pullup short makes the network code a lot more compact, which is a significant benefit. Robert N M Watson Computer Laboratory University of Cambridge > > from memory it is something like: > > if (m->m_len < headerlen && (m = m_pullup(m, headerlen)) == NULL) { > log(LOG_WARNING, > "nglmi: m_pullup failed for %d bytes\n", headerlen); > return (0); > } > header = mtod(m, struct header *); > > >>> >>> 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 >> > >