From owner-freebsd-current Wed Nov 27 12:55:12 2002 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 107A537B404 for ; Wed, 27 Nov 2002 12:55:11 -0800 (PST) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E6DB43E4A for ; Wed, 27 Nov 2002 12:55:10 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by sccrmhc01.attbi.com (sccrmhc01) with ESMTP id <2002112720550900100qpduve>; Wed, 27 Nov 2002 20:55:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA63235; Wed, 27 Nov 2002 12:51:28 -0800 (PST) Date: Wed, 27 Nov 2002 12:51:27 -0800 (PST) From: Julian Elischer To: Bosko Milekic Cc: current@FreeBSD.org Subject: Re: mbuf header bloat ? In-Reply-To: <20021127153543.A80168@unixdaemons.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 27 Nov 2002, Bosko Milekic wrote: > > On Wed, Nov 27, 2002 at 11:56:33AM -0800, Julian Elischer wrote: > > On Wed, 27 Nov 2002, Robert Watson wrote: > > > I'd like to continue to explore options for reducing the number of memory > > > allocations to extend storage on mbufs. One idea I've been tossing around > > > is adopting Jeff Roberson's extension model used in struct proc and > > > related structures. > > > > I've been wondering about a couple of things.. > > 1/ soemtiems I wonder if ALL mbufs should not be external mbufs. > > > > In other words, if the mbuf were always just a header and data was > > always stored on an external buffer it might actually simplify some > > code. It would then become possible that some tag space > > be allocated along with the mbuf header.. if MAC was > > in the system, then every mbuf would be allocated with a MAC tag by > > default. Maybe as a single allocation. The UMA allocator's init() > > capability gives us a lot of latitude in doing things like that. > > I don't see how that would simplify anything. You would still need > two allocations for external storage because you need to offer > third-party code the possibility to provide its own external storage > type (think jumbo bufs or sendfile(2) or the zero-copy code). You > don't really gain anything except for maybe potential space wastage > for very small packets by "always allocating an mbuf with external > storage" (you may only save a really quick and negligeable size > comparison, but that's it). I was thinking of having a selection of sized external buffers. small, medium, big.. really it was only a thought. > > As for non-third-party type external storage (your standard 2K mbuf > clusters) those can be allocated in one shot with an mbuf pre-attached > to it by the existing allocator anyway and an interface is provided to > do so (m_getcl(), iirc). true.. if it has a 'size' argument it would do what I was thinkng about.. > > -- > Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message