Date: Mon, 25 Nov 2002 09:48:15 -0800 From: Luigi Rizzo <rizzo@icir.org> To: Robert Watson <rwatson@freebsd.org> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, current@freebsd.org Subject: Re: mbuf header bloat ? Message-ID: <20021125094815.F20370@xorpc.icir.org> 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: ... > This weekend I spent about six hours looking at what it would take to move > MAC label data into m_tags. While in theory it is a workable idea, it > turns out our m_tag implementation is fairly far from being ready to > handle something like this. I ran into the following immediate problems: <list of problems omitted> yes, what you mention are certainly critical issues that need to be dealt with. The need for special constructor/destructors might be a bit troublesome to get right -- i.e. you'd want the extra info not to take too much space in the m_tag_header, which in turn might be solved by replacing the tag type/subtype with a pointer to an m_tag descriptor which in turn contains all the relevant attributes for the object. At which point we are recreating C++'s vtables ? But this is not necessarily bad from the point of view of efficiency, because i guess right now you have specific sections of code to take care of allocation/deallocations which could be moved to the mbuf handling routines ? > 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 individual mbufs are typically used in the output path for locally originated data, where the code still tries to optimize for size. E.g. if you writes to TCP sockets in small chunks, you might end up getting chains of individual mbufs instead of merging them into larger clusters (this is how, for example, Prafulla found out that ip_output() ended up being called with a chain of 64 or so mbufs for a single packet on an interface using jumbo frames!) The mbuf bloat has two aspects -- first it does have some cost to initialize and reset all these extra fields (and it is bug prone -- witness is the missing cleanup in m_getcl(), because m-tags were introduced after m_getcl() and probably it was forgotten); second, a legitimate question might arise at some point on why some features deserve to go there and others don't, and unfortunately the mac label constitutes a very bad precedent because it is very large and not very widely used (at list now) thus failing the two main important criteria for selection what should be in and what should not. cheers luigi ----------------------------------+----------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2988 ----------------------------------+----------------------------------------- cheers luigi 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?20021125094815.F20370>