Date: Tue, 7 Apr 2009 10:26:31 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: Sepherosa Ziehau <sepherosa@gmail.com>, freebsd-net@freebsd.org, Ivan Voras <ivoras@freebsd.org> Subject: Re: Advice on a multithreaded netisr patch? Message-ID: <alpine.BSF.2.00.0904071025450.45341@fledge.watson.org> In-Reply-To: <49DAF447.5020407@elischer.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> <ea7b9c170904062209tda44636tb9a18755ec0c5bb3@mail.gmail.com> <49DAF447.5020407@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0904071025450.45341>