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 [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
