Date: Tue, 7 Apr 2009 16:12:03 -0400 (EDT) From: Garrett Wollman <wollman@hergotha.csail.mit.edu> To: rwatson@freebsd.org Cc: net@freebsd.org Subject: Re: Advice on a multithreaded netisr patch? Message-ID: <200904072012.n37KC3lA050334@hergotha.csail.mit.edu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200904072012.n37KC3lA050334>