Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Nov 2002 13:09:00 -0500
From:      Bosko Milekic <bmilekic@unixdaemons.com>
To:        Robert Watson <rwatson@freebsd.org>
Cc:        Andrew Gallatin <gallatin@cs.duke.edu>, Luigi Rizzo <rizzo@icir.org>, current@freebsd.org
Subject:   Re: mbuf header bloat ?
Message-ID:  <20021125130900.C75177@unixdaemons.com>
In-Reply-To: <Pine.NEB.3.96L.1021125111737.36232C-100000@fledge.watson.org>; from rwatson@freebsd.org on Mon, Nov 25, 2002 at 11:31:39AM -0500
References:  <15840.8629.324788.887872@grasshopper.cs.duke.edu> <Pine.NEB.3.96L.1021125111737.36232C-100000@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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.

> Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
> robert@fledge.watson.org      Network Associates Laboratories

-- 
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?20021125130900.C75177>