Date: Fri, 24 Apr 1998 15:05:42 -0700 From: Julian Elischer <julian@whistle.com> To: dg@root.com Cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, Snob Art Genre <benedict@echonyc.com>, kjc@csl.sony.co.jp, current@FreeBSD.ORG Subject: Re: Bandwidth throttling etc. Message-ID: <35410CB6.353C51DE@whistle.com> References: <199804242149.OAA06768@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Greenman wrote: > > >> 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. At TFS we have been doing this in FreeBSD/MACH/BSD4.3/BSD4.2 since 1988. That's why I added the code that allows an arbitrary free() and add-refference() function to be pointed to in an external mbuf. We have 2MB ram on the network cards (sometimes more/less) and we treat the mbufs as just a header. the actual buffers are allocated by the card drivers, from ram ON THE CARD and linked onto an mbuf for transport through the protocol stacks. for what it's worth, LINUX uses a single pbuf to hold an entire packet. though I haven't looked at all the ins and outs of what they do. > > -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 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?35410CB6.353C51DE>