Date: Wed, 27 Feb 2002 10:58:13 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Jeff Roberson <jroberson@chesapeake.net>, arch@FreeBSD.ORG Subject: Re: mbuf allocation. (was: Slab allocator) Message-ID: <Pine.BSF.4.21.0202271051280.97278-100000@InterJet.elischer.org> In-Reply-To: <20020227124945.A29065@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0202271051280.97278-100000>