Date: Tue, 20 Aug 2002 13:36:50 -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: <20020820133650.C49141@iguana.icir.org> In-Reply-To: <15714.33482.820805.887447@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Tue, Aug 20, 2002 at 01:56:26PM -0400 References: <15714.27671.533860.408996@grasshopper.cs.duke.edu> <20020820093939.B48541@iguana.icir.org> <15714.33482.820805.887447@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 20, 2002 at 01:56:26PM -0400, Andrew Gallatin wrote: ... > > 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); > > This makes a lot of sense. > > > + 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); > > I'm missing something here. Isn't m_freem() implemented in terms of > m_free() now? yes, but that costs you an extra function call per mbuf in m_freem(). Because m_free() is just "free only the first mbuf", in many places (where the chain is guaranteed to be one buffer) you can just interchange them. Not long ago i even fixed a few places were m_free() was erroneously used instead of m_freem(). I guess the only places where m_free() makes sense is in the socket stack when you get rid of part of the chain after a successful uiomove(), in which case you could just temporarily save the m_next field for the last mbuf you want to free, and call m_freem() only once. In the end this should also save time, and maybe remove the need of m_free() altogether. 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?20020820133650.C49141>