Date: Wed, 19 Jun 2002 23:37:21 -0400 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: "Kenneth D. Merry" <ken@kdm.org>, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot Message-ID: <20020619233721.A30669@unixdaemons.com> In-Reply-To: <15633.17238.109126.952673@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Wed, Jun 19, 2002 at 10:52:06PM -0400 References: <20020618223635.A98350@panzer.kdm.org> <xzpelf3ida1.fsf@flood.ping.uio.no> <20020619090046.A2063@panzer.kdm.org> <20020619120641.A18434@unixdaemons.com> <15633.17238.109126.952673@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 19, 2002 at 10:52:06PM -0400, Andrew Gallatin wrote: > > Bosko Milekic writes: > > > > - It's kind of unfortunate that uipc_jumbo.c has to roll its own > > allocator; There are a couple of alternatives; to just use > > The point of uipc_jumbo.c rolling its own allocator is that it > allocates free pages which can be "flipped" (re-mapped) into > user-space to avoid a memory copy. The use of this allocator is > confined to nic's with firmware which is smart enough to split off > headers from payloads. (Currently only Ken's modified if_ti.c; and my > old Trapeze/Myrinet driver though I plan to implment this in the > official Myricom GM firmware/FreeBSD driver if the zero-copy sockets > patch is committed). 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. 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. However, I'm looking at the 18th of June patch from the same webpage and I still see that the uipc_jumbo.c code does not use the SLIST_FIRST macro. I think with those two bogons fixed, and assuming that the stuff in if_ti is OK, this is almost ready to go in under the ZERO_COPY kernel option? *gulp* [...] > 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. > Drew -- Bosko Milekic bmilekic@unixdaemons.com bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020619233721.A30669>