Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Mar 2002 23:44:53 -0500
From:      Bosko Milekic <bmilekic@unixdaemons.com>
To:        Jeff Roberson <jroberson@chesapeake.net>
Cc:        Mike Silbersack <silby@silby.com>, net@FreeBSD.ORG
Subject:   Re: Getting rid of maxsockets.
Message-ID:  <20020321234453.A96524@unixdaemons.com>
In-Reply-To: <20020321233416.B41335-100000@mail.chesapeake.net>; from jroberson@chesapeake.net on Thu, Mar 21, 2002 at 11:35:52PM -0500
References:  <20020322025429.K3059-100000@patrocles.silby.com> <20020321233416.B41335-100000@mail.chesapeake.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On Thu, Mar 21, 2002 at 11:35:52PM -0500, Jeff Roberson wrote:
> On Fri, 22 Mar 2002, Mike Silbersack wrote:
> 
> > There's one big target, though:  mbufs.  I know that Bosko put a lot of
> > work into his new mbuf allocator, but if you could find a way to merge
> > mbufs into the slab allocator the benefits would be huge.  Have you
> > discussed doing this with Bosko yet?
> >
> > Mike "Silby" Silbersack
> >
> 
> We have talked about it quite a bit.  I'd love to remove the hard limit on
> mbufs.  I may do this soon, but I have other uma related work that will
> probably come before it.

  I'm not so sure I like this idea.  What would be better (and perhaps
what you meant) is: "be able to expand the size of the mbuf allocation
`pool' at runtime."  In any case, we should not jump to quick
conclusions with all data structures right away.  Instead, I propose
that we first glue-in mbuf allocations to UMA (not too difficult, given
that UMA provides an allocation routine stub).  If this is done properly
[without macro-performance loss] then it should be rather trivial to
bring in new functionality.

> Jeff

-- 
Bosko Milekic
bmilekic@unixdaemons.com
bmilekic@FreeBSD.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?20020321234453.A96524>