Date: Wed, 13 Nov 1996 08:22:26 -0800 From: bmah@cs.berkeley.edu (Bruce A. Mah) To: Chris Csanady <ccsanady@friley216.res.iastate.edu> Cc: dyson@freebsd.org, gibbs@freefall.freebsd.org (Justin T. Gibbs), roberto@keltia.freenix.fr, freebsd-current@freebsd.org Subject: Re: pbufs (was: Re: ufs is too slow?) Message-ID: <199611131622.IAA03524@premise.CS.Berkeley.EDU> In-Reply-To: Your message of "Wed, 13 Nov 1996 07:15:18 CST." <199611131315.HAA03860@friley216.res.iastate.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris Csanady writes: > VJ's pbufs? ive not heard of these before, what are they? i remember hearin > g > something about him rewriting the tcp/ip stack to work well on gigabit > networks... this wouldnt have anything to do with it, would it? probably > not i suppose, but if anyone could point me to papers on anything related, id > apreciate it. :) I don't think Van has written any papers, but he's given a few talks on it. Going largely from memory: One of the losses of the current BSD TCP/IP implementation is that the unit of memory allocation (mbufs) doesn't really match the unit of network transmission. You'd like to allocate memory in packet- (or frame-) sized chunks, e.g. ~1500 bytes for Ethernet, rather than small mbufs (~112 bytes) or page mbufs (4K) which require a lot of copying and munging around of data. So the idea behind pbufs is that the lower protocol layers expose enough details to higher layers (e.g. the socket layer and TCP) to make this feasible. This also dovetails rather nicely with some assertions he's made about putting memory on network interfaces and mapping them into kernel memory (e.g. using the card's memory as socket/protocol buffers). One example of this is the Medusa/Afterburner series of high-speed network interfaces from HP/HP Labs. (Editorial note: Packet traces have shown that many packets, at least on LANs, tend to be small. So it's not clear to me what effect this would have for "typical" network traffic, though the wins for large bulk transfers have shown to be substantial.) Some of the other modifications also streamlined the protocol processing by combining layers (in the implementation, not protocol design). By doing several layers at once you can save overhead. Layering is great when designing a protocol stack, but many times not so great when you go to build something. Somewhere in the mess I call a desk I think I have hardcopies from a talk he gave on this stuff at a Gigabit TCP workshop a few years ago, but a cursory search has not revealed it. Bruce.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611131622.IAA03524>