From owner-freebsd-net Wed Sep 13 18:41: 3 2000 Delivered-To: freebsd-net@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id 3610E37B422 for ; Wed, 13 Sep 2000 18:40:56 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.ca ([24.201.203.136]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G0U00JLBSO6S2@falla.videotron.net> for freebsd-net@FreeBSD.ORG; Wed, 13 Sep 2000 21:40:55 -0400 (EDT) Date: Wed, 13 Sep 2000 21:44:25 -0400 (EDT) From: Bosko Milekic Subject: Re: Clusters larger than PAGE_SIZE and contigmalloc() In-reply-to: <20000913171611.E12231@fw.wintelcom.net> X-Sender: bmilekic@jehovah.technokratis.com To: Alfred Perlstein 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, Alfred Perlstein wrote: > Well I attempted to use clusters larger than PAGE_SIZE without > contigmalloc not realizing that there was no bus_space_foo for > mbufs. It wasn't fun debugging that. Mike Smith suggested that > I investigate how NetBSD handles this situation, I looked and it > seemed somewhat ok, but at a glance somewhat inneficient. If I recall correctly, you tried allocating your own external buffer. I'm actually wondering whether the kproc that is initialized in the case where MCLBYTES (the constant) is increased by the developer/whoever to something > PAGE_SIZE is still being used, and what the results are if it is. That's the part I'd like to scrap (you see a lot of #if MCLBYTES > PAGE_SIZE junk around the mbuf code). > Well, if you could do the bus space stuff for mbufs that would be > optimal, I'm sure the ethernet driver authors wouldn't have much > trouble migrating over to it. The drivers that typically require these larger buffers are usually the gigabit network adapters that do jumbo frames. I think that some of this hardware actually supports DMAing into several different buffer areas - I wonder if someone more familiar with this (like one of the guys working on the socket zero-copy code, or Bill Paul) could confirm this... > -Alfred Cheers, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message