Date: Sun, 24 Nov 2002 16:23:33 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Julian Elischer <julian@elischer.org> Cc: Robert Watson <rwatson@freebsd.org>, Luigi Rizzo <rizzo@icir.org>, current@freebsd.org Subject: Re: mbuf header bloat ? Message-ID: <15841.17237.826666.653505@grasshopper.cs.duke.edu> In-Reply-To: <Pine.BSF.4.21.0211232306410.28833-100000@InterJet.elischer.org> References: <15840.8629.324788.887872@grasshopper.cs.duke.edu> <Pine.BSF.4.21.0211232306410.28833-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer writes: > > > On Sat, 23 Nov 2002, Andrew Gallatin wrote: > > > > > As you eloquently state, there are a number of tradeoffs involved. On > > a 64-bit platform, 99% of users are paying 40 bytes/pkt for something > > that they will never use. On x86, 99.99% of users are paying 20 > > bytes/pkt for a feature they will never use. At least a signifigant > > fraction of nics make use of csum offloading (xl, ti, bge, em, myri). > > > the downside to the TAG stuff is that you need to allocate a separate > tag storage, and that is a malloc.. which has certain characteristics > vs the mbuf allocator. We have a special allocator for mbufs for a > reason. (I'm not sure how many of the original reasons still apply). > so it's worth looking at whether malloc is a suitable method of > allocating all that stuff before we take it out of the mbuf. > If we're going to nitpick the mbuf system, a much, much worse problem is that you cannot allocate an mbuf chain w/o holding Giant, which stems from the mbuf system eventually calling kmem_malloc(). This effectively prevents any network driver from being giant-free. When mbufs are low, mb_alloc() calls mb_pop_cont(). This, in turn, calls kmem_malloc() which requires Giant... The mbuf system calls malloc in other ways too. The first time you use a cluster, m_ext.ext_ref_cnt is malloc()'ed, and malloc is called when the mbuf map is expanded... I assume malloc will eventually call kmem_malloc(), leading to the same locking problems. I know that both tru64 and aix just malloc their mbufs. Drew 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?15841.17237.826666.653505>