From owner-freebsd-arch Wed Feb 27 11: 0:19 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 19E0737B41A for ; Wed, 27 Feb 2002 11:00:17 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020227190016.RGDA2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Wed, 27 Feb 2002 19:00:16 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA01167; Wed, 27 Feb 2002 10:58:14 -0800 (PST) Date: Wed, 27 Feb 2002 10:58:13 -0800 (PST) From: Julian Elischer To: Bosko Milekic Cc: Jeff Roberson , arch@FreeBSD.ORG Subject: Re: mbuf allocation. (was: Slab allocator) In-Reply-To: <20020227124945.A29065@unixdaemons.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@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 Feb 2002, Bosko Milekic wrote: > > (iii) For what concerns mbuf allocations, I don't know what to tell > you right now. Ultimately, I would like to see uma eventually > replace mb_alloc. However, I would like to make sure that the > transition is smooth and painless and that we don't lose any > performance. This is why I think that co-existing uma with all > existing code (see (ii)) is a good idea. Then, if you're > willing, I would be glad to help "attach" mbuf allocations to > uma, should that be possible and should we decide, as a group, > that that is what we want to do. On the topic of mbuf allocation: if we have a slab allocator it wouldn't matter if we have a 3rd size of mbuf, just the size of a mbuf header structure (with packet header) that gets used whenever a cluster-mbuf combo is allocated. This fits in with the comment that someone made recently about having an allocator function for a mbuf+cluster instead of having the caller allolcate one and hte add a cluster to it. I know of no code that takes an mbuf cluster, strips off the cluster, and then uses it as a normal mbuf, so the extra 200 bytes being carried around is always wasted. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message