From owner-freebsd-current Fri Apr 24 14:51:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA08320 for freebsd-current-outgoing; Fri, 24 Apr 1998 14:51:58 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA08313 for ; Fri, 24 Apr 1998 14:51:55 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id OAA06768; Fri, 24 Apr 1998 14:49:35 -0700 (PDT) Message-Id: <199804242149.OAA06768@implode.root.com> To: Luigi Rizzo cc: benedict@echonyc.com (Snob Art Genre), kjc@csl.sony.co.jp, current@FreeBSD.ORG Subject: Re: Bandwidth throttling etc. In-reply-to: Your message of "Fri, 24 Apr 1998 21:32:19 +0200." <199804241932.VAA22011@labinfo.iet.unipi.it> From: David Greenman Reply-To: dg@root.com Date: Fri, 24 Apr 1998 14:49:35 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Stevens suggests on p. 297 of TCP/IPv3 that "It appears that an mbuf >> cluster should be used sooner (e.g.for the 100-byte point) to reduce the >> processing time." >> >> What are the relative merits of increasing the size of mbufs vs. going >> right to clusters? > >a cluster is 2 KB, an mbuf is 8-16 times smaller. >Moreover, a cluster also requires an associated mbuf, so you lose in >locality of references, etc. > >I may be completely wrong, but I'd say that the most effective thing >would be to have mbufs large enough to hold the whole packet in most >cases. It remains to see how much memory you can afford to waste. mbufs should become just headers for variable sized allocations, rather than the current composite of a header and buffer; this would allow many interesting things to happen. There should probably be power of two sized buffers starting at 64 bytes and going up through at least the hardware page size, and as Garrett pointed out, there should be a machanism for the network device to manage what gets allocated/deallocated. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message