From owner-freebsd-current@FreeBSD.ORG Thu Jun 3 08:58:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D65D16A4CE; Thu, 3 Jun 2004 08:58:55 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id A118C43D1D; Thu, 3 Jun 2004 08:58:54 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (24-161-166-146.san.rr.com [24.161.166.146]) by smtp-relay.omnis.com (Postfix) with ESMTP id CA4081880C38; Thu, 3 Jun 2004 08:58:48 -0700 (PDT) From: Wes Peters Organization: Softweyr.COM To: freebsd-hackers@freebsd.org Date: Thu, 3 Jun 2004 08:58:47 -0700 User-Agent: KMail/1.6.1 References: <20040602141234.GA33162@freefall.freebsd.org> In-Reply-To: <20040602141234.GA33162@freefall.freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406030858.47817.wes@softweyr.com> X-Mailman-Approved-At: Fri, 04 Jun 2004 05:12:04 -0700 cc: Gleb Smirnoff cc: freebsd-current@freebsd.org cc: Bosko Milekic Subject: Re: [HEADS-UP] mbuma is in the tree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 15:58:55 -0000 On Wednesday 02 June 2004 07:12, Bosko Milekic wrote: > > If you read the paper on mbuma, you'll notice that I point out that it > would be worth investigating whether, in scenarios where an m_tag is > ALWAYS required per packet (e.g., MAC), providing a secondary zone with > pre-allocated m_tags for packet headers might be worth it. Prior to > this work, however, I suggest we investigate the possibility of using > smaller mini-mbufs whenever clusters are used so that space wastage > is reduced. It may also be worthwhile investigating eliminating clusters entirely. This is the point Poul-Henning, Robert and I were trying to make at the end of you talk at BSDCan. Since the double allocation required to create a cluster makes the locking (and cache slushing) requirements go up, it is probably worthwhile to investigate if raising the nominal mbuf size doesn't end up decreasing overall memory pressure. If you allocate more memory, but the allocation takes less time due to the simpler locking, you may actually decrease the total memory need. This is worth investigating partly because it is such a simple change. I propose investigating with mbuf size of 2K, large enough to fit standard ethernet frames, and a cluster size of 8K, which means a cluster mbuf is large enough to hold a 9K jumbo frame. Now that you've got mbuma in the tree, I can test this for you, unless this proposal catches your interest enough to give it a try. I'll see if I can't get a couple of our beefier machines at work updated to -CURRENT in the next week. Thanks for the good work. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com