Date: Tue, 20 Aug 2002 09:39:39 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance Message-ID: <20020820093939.B48541@iguana.icir.org> In-Reply-To: <15714.27671.533860.408996@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Tue, Aug 20, 2002 at 12:19:35PM -0400 References: <15714.27671.533860.408996@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 20, 2002 at 12:19:35PM -0400, Andrew Gallatin wrote:
>
> The current code for stocking the mcl_pool is located in m_freem().
> This is fine for forwarding, however the most commonly used receive
> path in soreceive() frees mbufs via m_free() (uipc_socket.c:868 in
> today's -stable). This means that on a machine which is an endpoint,
> rather than a forwarder, the mcl_pool will spend much of its time
> empty.
>
> Is there any reason why the mcl_pool is not stocked in m_free()
> rather than m_freem()?
a couple, both of which are probably rather weak:
#1 my (mis)assumption that m_free() was mostly unused;
#2 the assumption (this one possibly more correct) that the mbufs
freed by the socket layer do not have M_PKTHDR set, so when it
comes to initialize the mcl_pool from these ones you have more
work to do.
My impression is that it might be useful to do the following:
+ expand MFREE() in the body of m_freem() thus saving the extra
function call at each iteration of m_freem() (which is a cost
paid by all drivers);
+ rewrite m_free() in terms of m_freem(), either as a function or
maybe a macro (for critical paths -- not sure how often it is
used in critical paths);
now if you have patches i'll be happy to have a look at them.
cheers
luigi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020820093939.B48541>