From owner-freebsd-net Thu Jun 20 8:24:47 2002 Delivered-To: freebsd-net@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 2673B37B406; Thu, 20 Jun 2002 08:24:37 -0700 (PDT) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id LAA02499; Thu, 20 Jun 2002 11:24:35 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g5KFO5I30340; Thu, 20 Jun 2002 11:24:05 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15633.62357.79381.405511@grasshopper.cs.duke.edu> Date: Thu, 20 Jun 2002 11:24:05 -0400 (EDT) To: Bosko Milekic Cc: "Kenneth D. Merry" , current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot In-Reply-To: <20020619233721.A30669@unixdaemons.com> References: <20020618223635.A98350@panzer.kdm.org> <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu> <20020619233721.A30669@unixdaemons.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bosko Milekic writes: > > On Wed, Jun 19, 2002 at 10:52:06PM -0400, Andrew Gallatin wrote: <...> > Yes, I know that that's what it does. What I meant was that it would > be convenient to have UMA handle the allocation bit. It should be > possible to have UMA do this sort of allocation and keep the free pages > in per-CPU caches. The problem right now, as you know, is that UMA > (nor mb_alloc for that matter) will allow you to play those vm-tricks > you play on the allocated pages. I was just pointing out that it is an > unfortunate thing and that, hopefully, UMA will allow for this sort of > thing at some point in the future. Ah, OK, point taken. I'm sorry if I gave offense. > By the way, my other two comments have been deleted, but reading the > page that Ken maintains I noticed that Alfred already pointed them out. <...> Ken has been maintaining the patchset on his own for quite some time. I must admit that I've not looked closely at these issues, so I didn't feel it was appropriate for me to comment on them. I didn't mean to discount your other comments. > [...] > > This is orthogonal to the zero-copy patch, but it _would_ be nice to > > have general purpose mbuf allocator which could allocate mbuf clusters > > with 9K physically contigous for dumber nics. There are a whole slew > > of drivers (unpatched ti, bge, nge, lge, etc) which roll their own for > > no better reason than the system doesn't offer this feature. That's > > what needs fixing. Heck, if such an allocator was available, we could > > use it for copyin's of large chunks of data. Tru64 has 8K and 2K > > clusters and does this. (based from emperical evidence garnered at the > > driver level). > > Right. It's very hard to do > PAGE_SIZE allocations that are backed > by physically contiguous memory in FreeBSD right now. I agree that this > would be very useful, though. > Years ago, I used Wollman's MCLBYTES > PAGE_SIZE support (introduced in rev 1.20 of uipc_mbuf.c) and it seemed to work OK then. But having 16K clusters is a huge waste of space. ;). Do you think it would be feasable to glue in a new jumbo (10K?) allocator on top of the existing mbuf and mcl allocators using the existing mechanisms and the existing MCLBYTES > PAGE_SIZE support (but broken out into separte functions and macros)? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message