From owner-freebsd-current Mon Nov 25 10:37:10 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA94837B401 for ; Mon, 25 Nov 2002 10:37:08 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D2E843EAF for ; Mon, 25 Nov 2002 10:37:08 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id gAPIZ3BF043092; Mon, 25 Nov 2002 13:35:03 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 25 Nov 2002 13:35:02 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Bosko Milekic Cc: Andrew Gallatin , Luigi Rizzo , current@freebsd.org Subject: Re: mbuf header bloat ? In-Reply-To: <20021125130900.C75177@unixdaemons.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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