From owner-freebsd-net Tue Aug 20 9:39:43 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 B038537B400 for ; Tue, 20 Aug 2002 09:39:41 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ED9E43E72 for ; Tue, 20 Aug 2002 09:39:41 -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 g7KGddIb048746; Tue, 20 Aug 2002 09:39:39 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g7KGddf0048745; Tue, 20 Aug 2002 09:39:39 -0700 (PDT) (envelope-from rizzo) Date: Tue, 20 Aug 2002 09:39:39 -0700 From: Luigi Rizzo To: Andrew Gallatin Cc: freebsd-net@FreeBSD.ORG Subject: Re: m_getcl and end-to-end performance Message-ID: <20020820093939.B48541@iguana.icir.org> References: <15714.27671.533860.408996@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.27671.533860.408996@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Tue, Aug 20, 2002 at 12:19:35PM -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 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