Date: Mon, 25 Nov 2002 13:35:02 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Bosko Milekic <bmilekic@unixdaemons.com> 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.1021125133206.42342B-100000@fledge.watson.org> In-Reply-To: <20021125130900.C75177@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 25 Nov 2002, Bosko Milekic wrote: > On Mon, Nov 25, 2002 at 11:31:39AM -0500, Robert Watson wrote: > > BTW, do you have any recent large-scale measurements of packet size > > distribution? In local tests and measurements, the additional 20 bytes on > > i386 didn't bump the remaining mbuf data space sufficiently low to > > substantially change the behavior of the stack. However, I haven't done > > measurements against the 64-bit variation. In practice, a number of > > network interfaces now seem to use clustered mbufs and not attempt to use > > the in-mbuf storage space... All my packet distribution measurements come > > from a typical ISP environment, but may not match what is seen in > > large-scale backbone environments. > > I am equally curious about this. One of the design assumptions for > mbufs and clusters, according to McKusick et al. (and I believe > another text which currently escapes me) is that packets are typically > either very small or fairly large. Given the MAC label additions > (yes it would be nice if this was done using the m_tag interface but > at the very least one can say that they are implemented fairly > 'consistently' despite the fact that they appear imposing to the > general mbuf structure), and the currently available data region in > the mbuf, it is absolutely necessary to know whether the assumption of > packet size distribution still holds before a decision is made on how > to modify the MAC label implementation - if at all. It's worth pointing out for those listening, and as I'm sure you're already aware, m_tag was not available for use by the MAC Framework when we did any of the design and implementation, and m_tags were committed to the tree about three months after the MAC work. I'm happy to look at switching the mechanism used for MAC to m_tag, especially once m_tag is mature enough to be used, but it wasn't a design consideration in our first pass simply because it didn't exist :-). 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.1021125133206.42342B-100000>