Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Jun 2002 11:24:05 -0400 (EDT)
From:      Andrew Gallatin <gallatin@cs.duke.edu>
To:        Bosko Milekic <bmilekic@unixdaemons.com>
Cc:        "Kenneth D. Merry" <ken@kdm.org>, current@FreeBSD.ORG, net@FreeBSD.ORG
Subject:   Re: new zero copy sockets snapshot
Message-ID:  <15633.62357.79381.405511@grasshopper.cs.duke.edu>
In-Reply-To: <20020619233721.A30669@unixdaemons.com>
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

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-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15633.62357.79381.405511>