From owner-freebsd-net Wed Sep 13 19:59:38 2000 Delivered-To: freebsd-net@freebsd.org Received: from field.videotron.net (field.videotron.net [205.151.222.108]) by hub.freebsd.org (Postfix) with ESMTP id 2F10F37B423 for ; Wed, 13 Sep 2000 19:59:36 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.ca ([24.201.203.136]) by field.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G0U00M32WBAPU@field.videotron.net> for freebsd-net@FreeBSD.ORG; Wed, 13 Sep 2000 22:59:34 -0400 (EDT) Date: Wed, 13 Sep 2000 23:03:02 -0400 (EDT) From: Bosko Milekic Subject: Re: Clusters larger than PAGE_SIZE and contigmalloc() In-reply-to: <200009140222.WAA04696@khavrinen.lcs.mit.edu> X-Sender: bmilekic@jehovah.technokratis.com To: Garrett Wollman Cc: freebsd-net@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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