Date: Wed, 13 Sep 2000 23:03:02 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: freebsd-net@FreeBSD.ORG Subject: Re: Clusters larger than PAGE_SIZE and contigmalloc() Message-ID: <Pine.BSF.4.21.0009132234580.397-100000@jehovah.technokratis.com> In-Reply-To: <200009140222.WAA04696@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Sep 2000, Garrett Wollman wrote: [...] > 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] if_ti, if_wb, and at least one other already manage their own buffers. I don't like them, as they wire down too much physical memory, but they're probably the best thing we can do at this very instant. I wouldn't actually push for allocating mbufs themselves to that layer, simply because this isn't the only place we'd need to allocate mbufs from - but I don't think that's what you meant by the above anyway. > -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. Assuming we're dealing with a general purpose allocator, such as the kernel's malloc(), then I can see how this _may_ be profitable. However, if we're just allocating same-sized objects (or some small limited number of various sized objects), then wouldn't this just fragment the space? (i.e. 1536 < PAGE_SIZE and also not a power of 2). Bosko Milekic bmilekic@technokratis.com 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?Pine.BSF.4.21.0009132234580.397-100000>