From owner-freebsd-net Tue Aug 20 13:36:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 565A837B400 for ; Tue, 20 Aug 2002 13:36:52 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 029AD43E42 for ; Tue, 20 Aug 2002 13:36:52 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g7KKaoIb050275; Tue, 20 Aug 2002 13:36:50 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7KKao6T050274; Tue, 20 Aug 2002 13:36:50 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Aug 2002 13:36:50 -0700 From: Luigi Rizzo To: Andrew Gallatin Cc: freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance Message-ID: <20020820133650.C49141@iguana.icir.org> References: <15714.27671.533860.408996@grasshopper.cs.duke.edu> <20020820093939.B48541@iguana.icir.org> <15714.33482.820805.887447@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i 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 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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