Date: Wed, 19 Jun 2002 21:48:57 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, current@FreeBSD.ORG, net@FreeBSD.ORG Subject: Re: new zero copy sockets snapshot Message-ID: <20020619214857.C8221@panzer.kdm.org> In-Reply-To: <20020619233721.A30669@unixdaemons.com>; from bmilekic@unixdaemons.com on Wed, Jun 19, 2002 at 11:37:21PM -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> <20020619233721.A30669@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 19, 2002 at 23:37:21 -0400, Bosko Milekic wrote: > 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. It would be nice. Perhaps with an application for such functionality sitting in the tree, it might provide an incentive for someone to write the UMA code to do it. :) > 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* You're right, I fixed one instance but not the other two. Those are fixed in my local tree. If you've got some ideas on reducing the lock time in the ti(4) driver, I'd be glad to hear them. (As I said previously, I wouldn't worry too much about the memory copy functions, they're only used when the debugging interface is active.) > [...] > > 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. Thanks again for the feedback! Ken -- Kenneth Merry ken@kdm.org 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?20020619214857.C8221>