Date: Tue, 7 Apr 2009 13:09:37 +0800 From: Sepherosa Ziehau <sepherosa@gmail.com> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-net@freebsd.org, Ivan Voras <ivoras@freebsd.org> Subject: Re: Advice on a multithreaded netisr patch? Message-ID: <ea7b9c170904062209tda44636tb9a18755ec0c5bb3@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ea7b9c170904062209tda44636tb9a18755ec0c5bb3>