Date: Wed, 13 Sep 2000 22:22:37 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Bosko Milekic <bmilekic@dsuper.net> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Clusters larger than PAGE_SIZE and contigmalloc() Message-ID: <200009140222.WAA04696@khavrinen.lcs.mit.edu> In-Reply-To: <Pine.BSF.4.21.0009132132340.9365-100000@jehovah.technokratis.com> References: <20000913171611.E12231@fw.wintelcom.net> <Pine.BSF.4.21.0009132132340.9365-100000@jehovah.technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 13 Sep 2000 21:44:25 -0400 (EDT), Bosko Milekic <bmilekic@dsuper.net> said: > The drivers that typically require these larger buffers are usually > the gigabit network adapters that do jumbo frames. The code was originally written for an ATM driver than never saw the light of day, as I recall. Prior to that, you could specify a large cluster size, but there was no guarantee that the pages in the cluster would be physically contiguous, and the hardware in question did not support scatter/gather DMA. (Some of the code which did not make it into FreeBSD supported embedding the header mbuf into the cluster, a feature which would still be a good idea today.) I don't think there is anybody who still cares about that code now; it was just a stopgap measure on the way to something that never happened. The Right Way to do this, as I've been expounding for several years[0] (but never actually done the work) is to push mbuf allocation down into the driver, so that each interface can create precisely the sort of buffer that works best for it. Obviously, most Ethernet interfaces would share a common allocator, just as they do now.[1] -GAWollman [0] Van Jacobson has been saying it for at least twice as long. [1] It might be worthwhile for Ethernet interfaces to use 1536-byte clusters rather than 2048-byte clusters. 1536 is large enough to hold and Ethernet packet with complete headers, but packs eight buffers in the space of six 2kbyte clusters. With the new refcounting code this should be quite easy to accomplish. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009140222.WAA04696>