Date: Wed, 27 Nov 2002 19:11:37 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Julian Elischer <julian@elischer.org> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, Luigi Rizzo <rizzo@icir.org>, current@freebsd.org Subject: Re: mbuf header bloat ? Message-ID: <Pine.NEB.3.96L.1021127185955.50233J-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.21.0211271151510.52749-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Nov 2002, 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. These are all interesting possibilities. One of the upshots of this conversation is that it sounds like, while 5.x is stabilizing, we might want to consider some side experimental work to evaluate the continuing effectiveness of mbufs, and to experiment with alternatives. Between Bosko's new allocator and UMA, I think we're pretty set on optimizing for the current mbuf model fo 5.x. Finishing up and cleaning up the fine-grained locking and measuring the impact of current changes should keep us busy on the implementation side for a bit though. There seem to be a number of parts of this problem -- how changes in traffic, common interfaces, usage patterns, and memory allocators have changed our requirements for a network subsystem. I have the suspicion that the traffic patterns leading to an mbuf model will probably remain: most connections will remain assymetric in nature, with most of the large frames in one direction representing a bulk data transfer, and small frames in the other direction, representing the acknowledgement and control stream. TCP hasn't shown any signs of going to a model where we send large selective acknowledgement frames covering wide windows, which I suppose it might do at some point given the increase in minimum frame size. However, we have seen work to pack lots of small packets into large frames for bulk delivery in routers to avoid the loss of efficiency over medimums with large mininum frame sizes. Maybe we can put together a working group to do some discussion and experimentation. This is an area where we might be able to approach potential sponsors using FreeBSD for joint investment in network performance improvement. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories 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?Pine.NEB.3.96L.1021127185955.50233J-100000>