Date: Wed, 27 Nov 2002 15:35:43 -0500 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Julian Elischer <julian@elischer.org> Cc: current@FreeBSD.org Subject: Re: mbuf header bloat ? Message-ID: <20021127153543.A80168@unixdaemons.com> In-Reply-To: <Pine.BSF.4.21.0211271151510.52749-100000@InterJet.elischer.org>; from julian@elischer.org on Wed, Nov 27, 2002 at 11:56:33AM -0800 References: <Pine.NEB.3.96L.1021127095837.43889C-100000@fledge.watson.org> <Pine.BSF.4.21.0211271151510.52749-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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). 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). -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021127153543.A80168>