Date: Mon, 25 Nov 2002 14:19:31 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Robert Watson <rwatson@freebsd.org>, Andrew Gallatin <gallatin@cs.duke.edu>, Luigi Rizzo <rizzo@icir.org>, current@freebsd.org Subject: Re: mbuf header bloat ? Message-ID: <3DE2A1F3.E3084938@mindspring.com> References: <15840.8629.324788.887872@grasshopper.cs.duke.edu> <Pine.NEB.3.96L.1021125111737.36232C-100000@fledge.watson.org> <20021125130900.C75177@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bosko Milekic wrote: [ ... packet size distribution ... ] > 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. In fact, it is even more useful to consider the idea of variable sized mbufs. The actual size you want is "whatever size is needed for the incoming packets for the MTU of the sender". Practically, this means 8K (a compromise on the 9K "jumbograms" vs. page size), 1536 (512*3), etc.. I get concerned with all this decoration of mbufs (MAC vs. m_tag vs. whatever) that people are doing, since this type of thing is going to reduce overall capacity more than m_pullup(), etc.. -- Terry 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?3DE2A1F3.E3084938>